Remote health assertion verification and mortality prediction system

ABSTRACT

A computing system can implement a health verification and prediction service by generating an interactive user interface through which users can provide responses to health assertions in one or more trivia sessions. Each of the health assertions can include a correlation value to actual health outcomes based on responses received from individuals a control group and the known health outcomes of those individuals. Based on the responses from the user, the computing system can generate a health profile for the user.

RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No. 16/279,703, filed on Feb. 19, 2019; which is a continuation-in-part of U.S. patent application Ser. No. 15/273,585 (now U.S. Pat. No. 10,580,531), filed Sep. 22, 2016; which is a continuation-in-part of U.S. patent application Ser. No. 14/642,709 (now U.S. Pat. No. 10,629,293), filed Mar. 9, 2015; which is a continuation-in-part of U.S. patent application Ser. No. 14/542,347, filed Nov. 14, 2014 (now U.S. Pat. No. 10,672,519); the aforementioned applications being hereby by incorporated by reference in their respective entireties for all purposes.

TECHNICAL FIELD

Examples described herein relate to a computing system implementing a health validation and prediction service based on user knowledge and correlations with actual health outcomes of a control group of users.

BACKGROUND

Online services exist which provide interactive gaming and social environments for users. These services generally exist for amusement only.

There also exists a questionnaire, termed the Patient Activation Measure (“PAM”), provided by Insignia Health under license from the State of Oregon, which includes a static set of questions that are knowledge-based and deemed correlative to health.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates a system for predicting a physiological or mental health of a user based on the user's knowledge level of health, according to one or more embodiments.

FIG. 2 illustrates an analysis system, according to an embodiment.

FIG. 3 illustrates an example of a data structure that can be developed to link a question with a health outcome and a topic, according to one or more embodiments.

FIG. 4 illustrates an example method for predicting a health outcome of a user based in part on whether a user has independent knowledge of an assertion relating to health.

FIG. 5 illustrates an example method for predicting a health outcome of a user based on a knowledge profile of a user.

FIG. 6A illustrates an example method for providing a health related service to a user based on a knowledge-predicted health outcome for a user.

FIG. 6B illustrates a health service sub-system 680, according to an embodiment.

FIG. 7A illustrates an example method for providing a game-based environment in which user responses enable prediction of health outcomes for individual users.

FIG. 7B illustrates a knowledge-based recommendation engine, according to one or more embodiments.

FIG. 7C illustrates an example method for choosing questions to provide to a user based on data retrieved from an activity monitoring device.

FIG. 8A through 8H illustrate example interfaces for use with one or more embodiments described herein.

FIG. 9 is a block diagram that illustrates a computer system upon which embodiments described herein may be implemented.

FIG. 10 illustrates a real-world mortality information system, according to an embodiment.

FIG. 11 illustrates a system to categorize a lifestyle of a user, according to an embodiment.

FIG. 12 illustrates an automated method for utilizing information about a user, according to an embodiment.

FIG. 13 illustrates a health determination system for determining health-based products and services, according to an embodiment.

FIG. 14 is a block diagram illustrating an example computing system implementing remote health-assertion verification and health prediction using big data techniques, according to examples described herein.

FIGS. 15 and 16 are flow charts describing methods of remotely verifying self-assertions and predicting mortality and/or morbidity outcomes of a user, according to examples described herein.

DETAILED DESCRIPTION

Health service providers typically provide questionnaires or surveys to patients to make self-assessments and provide medical information. For example, the patient may be asked several questions regarding past medical history, any known medical issues (e.g., high blood pressure), and certain self-classifications, such as whether the patient identifies as an athlete, which type(s) of athletic activities the patient engages, whether and/or how much the patient exercises, whether the patient smokes tobacco, how much tobacco the patient smokes, how much alcohol the patient consumes, and the like. The patient may further provide personal information, such as age, weight, height, etc.

Such information can be utilized for a variety of purposes. One such purpose is to generate a health risk table (e.g., a morbidity table) to determine the health risks of the patient. Another purpose is to generate a mortality table that indicates a life expectancy or a likelihood of death within a given time frame (e.g., the next ten years). This information may also be used to individually provide health service benefits for the patient, or for customized pricing of health service products (e.g., life insurance or health insurance). However, current methods of remotely and accurately validating a patient's self-reported health claims are severely lacking. Accordingly, a physical health screening is necessary to accurately generate morbidity and/or mortality tables for patients, which increases inefficiency and cost. Thus, a technical problem of remotely and accurately validating a patient's self-reported health attributes—without the need for a physical visit and health screening—currently exists in the field of health services.

Big data analytics can be utilized by a computing system to determine correlations between the health-related knowledge of a user and the future health outcome(s) of that user. Specifically, a library of health-related assertions or questions can be provided to a broad user base in the form of a health trivia game (e.g., on the order of thousands or tens of thousands of specially constructed questions or assertions to millions or tens of millions of users). For example, the health trivia game can be provided to users in multiple choice form through an interactive user interface, in which the user is presented with health assertions or questions sequentially, and selects from a plurality of possible answers, of which only a single answer is correct. Over the course of multiple trivia sessions played by the user, the computing system can generate a health knowledge profile for the user, which can be segmented between several health topics (e.g., comprising a different health knowledge score for each health topic).

For example, the segmented health knowledge profile can indicate the user's expertise or lack thereof in a variety of health topics, each of which can be highly specific. Furthermore, as actual health outcomes of certain users of the user base become known, such users can be included in a control group upon which the computing system can perform correlation analysis between the health knowledge of control group users and the known health outcomes of those users. It is contemplated that expert level knowledge of certain health topics is highly correlative to a corresponding health outcome. For example, a high health knowledge score for a trivia session in which the user answers or provides responses to triathlon assertions can correlate to good cardiovascular health and normal blood pressure, based on the data analytics of the control group. Thus, the computing system can determine, based on a probability calculation using additional data, that a new user that receives a high score or an expert knowledge level in the topic(s) of triathlon has good cardiovascular health and good blood pressure (e.g., ranked as a percentile of the total population).

It is further contemplated that over time, the control group can increase as more and more health outcomes become known, which can either bolster or diminish the correlations, making them more accurate or less accurate. The computing system can filter out the less accurate correlations (e.g., health assertions in the trivia game having low correlation values), and maintain the highly accurate, highly correlative health assertions for use in the trivia application. Health, morbidity, and/or mortality outcomes can be identified by the computing system through various methods, such as self-reporting, scrolling through public databases (e.g., obituaries, social security death index, social media content), medical institution partnerships, and the like.

According to examples described herein, the computing system can compile and organize a library of health assertions and/or questions for an application-based or web-based trivia game. Each health assertion or question can be associated with one or more topics (e.g., one or more intensive medical topics, scientific health topics, nutritional topics, dietary topics, sporting topics, athletic or activity topics, hobby topics, habit topics, and the like). These topics can be utilized by the computing system to select assertions or questions to present to the user during a trivia session, along with multiple responses or answers from which to select. Furthermore, each health assertion or question can be meta-tagged or otherwise associated with one or more correlation values based on current correlation information from the ever-expanding control group (e.g., a health assertion may be 84% correlative to high cardiovascular health, 96% correlative to healthy weight or BMI, 44% correlative to normal respiratory health, 26% correlative to normal digestive health, 80% correlated to above-average mortality outcomes).

In addition, a customized mortality table or actuary table can be generated (e.g., through automation by the computing system) using the actual health data from the control group and the correlations with the health-related knowledge of control group users. In variations, a standard mortality table can be used to classify users. For example, the computing system can initially determine a user's position in a standard mortality table prior to the user taking the health quiz. After the health knowledge profile is generated for the user, the computing system can adjust the position of user in the standard mortality table using the user's position in the customized mortality table as a factor. As provided herein, the mortality table can comprise an age column and any number of additional columns that can be used to classify a user or a risk probability of the user (e.g., death probability, life expectancy, gender or sex, and the like).

In various implementations, the computing system can store a user profile for each user, indicating any medical information, personal information, health risks, a mortality table for the user (e.g., data indicating a user's health risks and/or position in a mortality table), and/or a morbidity table generated based in part on scores from previous health trivia sessions, the previous health trivia quizzes or questions that the user has answered, etc. In certain examples, when a user initiates a session for the first time, the user may be prompted to input or otherwise select from a set of classifications. These self-classifications can indicate the user's self-health impression. However, it is contemplated that the user's self-classifications may be misleading or misidentified based on, for example, attempts to lower a health insurance premium, masking an underlying health problem or habit (e.g., a smoking habit), conscious or unconscious self-deception, and the like. After the first-time user self-classifies, the computing system can select health assertions and/or questions for one or more subsequent trivia sessions in order to validate or invalidate the self-classifications by the user.

A health trivia session can be initiated by the user. In certain implementations, the user can directly initiate a session by selecting a topic, and thereafter provide responses to the trivia assertions presented by the computing system (e.g., via an interactive user interface generated by a health trivia application executing on the computing device of the user). The user can select from multiple responses, with one being a correct response, and others being either partially correct or incorrect. At the conclusion of the trivia session, the computing system can generate an individualized user interface element for the user on the interactive user interface, where the individualized user interface element comprises a health knowledge score based at least in part on the sequence of responses and and/or a comparison of the user's health knowledge compared to other users.

Based at least in part on the user's trivia session(s), and other information in the user profile of the user, the computing system can generate at least one of a mortality table for the user, the mortality table indicating a likelihood of death for the user over a given time frame. For example, the computing system can determine the user's position in the customized mortality table. Additionally or alternatively, the computing system can generate a morbidity table for the user, the morbidity table indicating one or more health risks of the user. In variations, the results of the user's trivia session(s), can enable the computing system to generate a health knowledge profile of the user, which the computing system can utilize to determine a position or location of the user in the mortality table, which can indicate a probability of death for the user within a given time frame (e.g., the next year). For example, the computing system can combine the profile information of the user (e.g., indicating, age, gender, medical information, vitals, current medical conditions, and/or health risks) with the user's health knowledge profile, a determined based on the user's performance in the health trivia session(s), to determine location of the user in the mortality table.

In various implementations, the mortality table, or life table, can be utilized by the computing system or one or more health service providers, and may be inaccessible or otherwise not viewable by the user. For example, an insurance provider can utilize the table(s) for creating a health or life insurance plan and pricing package. In further implementations, the computing system can utilize the health knowledge profile of the user, along with the profile information of the user, to generate a morbidity table, or otherwise determine the user's position within an existing morbidity table (e.g., a customized morbidity table that the computing system generates using control group data described herein). As provided herein, the morbidity table can indicate any current and/or future health risks of the user. For example, the morbidity table can list a set of illnesses and/or diseases, and for each illness and/or disease, the computing system can generate and input a probability that the user will be diagnosed with or otherwise experience symptoms of the illness or disease sometime in the user's lifetime, or over given timeframe (e.g., the next five years).

The examples described herein may be utilized to validate a user's self-classification claims, to accelerate an insurance underwriting process (e.g., performed totally remotely with no contact with the user), or in combination with remote conferencing (e.g., video conference with the user), a health screening process or physical, one or more remote health tests (e.g., a blood pressure test), and the like.

Some embodiments include a system and method for predicting a health outcome of a user based on a determination of knowledge the user possesses regarding issues of physiological or mental health.

Still further, in some embodiments, a system and method is provided for providing a health service benefit to a user based on their predicted health, as determined from the user's knowledge of human health.

In one embodiment, a collection of assertions are stored in which each assertion pertains to human health. For each individual in a control population of persons, a value of a predetermined health parameter is determined which is indicative of that person's health. For each assertion of the collection, a correlative health parameter is determined which is indicative of an association between those individuals in the control population that have independent knowledge of the assertion and the value of the predetermined health parameter for persons of the control population. The collection of assertions can be stored by associating each assertion with the determined correlative health parameter for that assertion. An interface is provided for a user to indicate the user's independent knowledge of each assertion in at least a subset of assertions from the collection. A health outcome is predicted for the user based at least in part on the correlative health parameter of individual assertions in the subset of assertions.

In still another embodiment, a health outcome of a user is predicted based on a knowledge profile determination of the user. In one embodiment, a knowledge profile is determined for the user which reflects the user's independent knowledge of individual assertions in a collection of assertions. A correlation is determined as between a set of facets of the user's knowledge profile and a corresponding set of facets of multiple individual person's knowledge profile. The knowledge profile can be determined for at least a set of assertions from the collection of assertions. A health outcome is determined for each of the multiple individual persons. The health outcome of the user can then be predicted based in part on the correlation and the health outcome of each of the multiple individuals.

In still another embodiment, a knowledge profile is determined for the user to reflect the user's independent knowledge of individual assertions in a collection of assertions. Each assertion in the collection can be non-specific to the user or to any person of the population, but otherwise known to be correlative to human health. A determination is made as to a first correlation value as between the knowledge profile of the user and a knowledge profile of a control group of persons for whom one or more health outcomes are known. A first health outcome is predicted for the user based on the first correlation value. A health service benefit is provided to the user based at least in part on the predicted health outcome.

Still further, according to another embodiment, a human health knowledge profile is determined for each user in a group of users, the human health knowledge profile reflecting that user's independent knowledge about assertions in a collection of assertions. Each assertion in the collection of assertions may pertain to human health and is non-specific as to any user or to any person of the population. At least a first correlation value is determined as between a facet of the knowledge profile of individual users in the group of users and a corresponding facet of the knowledge profile of a control group of persons for whom one or more health outcomes are known. A subset of one or more users is selected based on the first correlation value of each user of the subset exceeding a threshold designation. A service or designation is provided for a set value to the one or more users of the subset, and not to other users of the group. The service or designation may be associated with a true per-user cost that is not equal to the set value, but which is variable and set to increases over time when individual users in the subset suffer negative health consequences as a result of a naturally progressing medical condition. Still further, some embodiments include a system and method for providing a health service or benefit to a user. By way of examples a health service or benefit can include health insurance (including primary or supplemental), life insurance, enrollment in a facility to receive medical attention, medical publications, as well as discounts or augmented services thereof. In one embodiment, a collection of questions are stored, where each question is based on a documented assertion pertaining to human health. Each question in a first subset may be associated with a correlative health parameter that is based at least in part on (i) persons in a control population of that have independent knowledge of an assertion that is a basis of that question, and (ii) a value of a predetermined health parameter for each person in the control population the value of the predetermined health parameter for each person being indicative of that person's health. Additionally, the second subset of the questions is associated with a null (i.e. non-existent) or neutral (i.e., not indicative of health) correlative health parameter. A corresponding set of questions is displayed to the user from the collection for response for each user in the set of users. A response score is determined for each user in the set of users based on a correctness of their respective reply to each question in the corresponding set of questions. A health parameter value is determined for at least a health outcome based at least in part on the correlative health parameter of at least some questions in the corresponding set of questions.

Still further, some embodiments include a system and method for providing health recommendations to a user. In an embodiment, a plurality of questions are provided to the user. The plurality of questions can include multiple questions for each of multiple health-related topics, so that individual questions are each associated with one or more of the multiple topics. A score is determined for the user in answering each question in the plurality of questions. The score can include topical scores for one or more of the multiple topics. Based on the topical score of at least a first topic, a set of recommendations can be identified for the user. The set of recommendations may include an action that the user can perform to improve the user's mental or physiological health relating to the topic.

According to some embodiments, contextual data is determined from user activity, and more specifically, from health related activity recorded by a user device. The user device can correspond to, for example, a mobile device that the user can carry on their person (e.g., mobile device in arm holster), or by a wearable electronic device. By way of example, a wearable electronic device can include computerized devices that record movement, location, and/or a user's biometric output (e.g., temperature or heart beat). Wearable electronic devices can have a variety of form factors, such as, for example, a bracelet, watch, arm band, glassware, hat, or garment. Depending on design or implementation, such devices can operate independently or in communication with another computing device (e.g., via Bluetooth or wireless connection to another mobile computing device).

As used herein, an activity monitoring device includes any electronic device which the user can carry, such as a mobile computing device or wearable electronic device, which tracks and records user activity in the context of health. The recorded activity can include data relating to user exercise, as well as data relating to everyday activities such as sleeping, walking, eating, or working (e.g., sitting at desk). According to some embodiments, data generated by one or more activity monitoring devices is retrieved, and questions displayed to the user are based on this retrieved data.

While examples such as described are implemented on computer systems, empirical data has been derived to show health outcome prediction can be correlated to user's knowledge. For example, examples have determined that positive health outcome determinations made from evaluating user's answers directly correlate to fewer hospital stays.

System Overview

FIG. 1 illustrates a system for predicting a physiological or mental health of a user based on the user's knowledge level of health, according to one or more embodiments. A system 100 as shown by an example of FIG. 1 can be implemented using a combination of servers, or other computers which combine to provide a network service for client computers operated by a user base. While an example of FIG. 1 illustrates the system 100 being implemented as a combination of logical components, alternative implementations can readily provide for functionality described to be integrated or discrete. Moreover, specific combinations of functionality and processes described can alternatively be performed as sub-combinations or alternative combinations. Likewise, an example of FIG. 1 illustrates use of multiple data stores, which can logically and/or physically be implemented as a combined or integrated data structure (e.g., database), or alternatively, in distributed fashion such as shown.

Among other implementations, system 100 can be accessible to users 11 over a network 101, such as the World Wide Web, to mobile computing devices (e.g., feature phones, tablets, etc.), personal computers (e.g., desktop computers, laptops, etc.) and other user operated computing devices for purpose of interactively engaging individual users to determine their knowledge level on various health topics, and further for predicting the individual user's physiological or mental health based on their knowledge level of health. Among other advantages, an example of FIG. 1 enables facets of physiological or mental health to be determined for a person, without need for obtaining user specific medical information or biological samples. For example, in one implementation, a user's health can be predicted without use of any user-specific medical question. In a variation, a user's health can be predicted based only on inputs of gender and age. In another variation, data collected through activity monitoring devices can be used, alone or in combination with other inputs, to predict a user's health.

As described in greater detail, system 100 generates fact-based questions on various topics of health for purpose of (i) obtaining responses from users, (ii) correlating some of those responses to physiological or mental health determinations, and/or (iii) correlating some of those responses to predict a mortality outcome or underwriting class. One of the underlying assumptions of system 100 is that the living habits and behaviors of people generally tends to have a measurable impact on their physiological or mental health, particularly when the assumption is applied to a statistically significant sample of people (e.g., hundreds or thousands of persons). Under a statistically significant sample, embodiments described herein have recognized that a correlation can be made as between the knowledge or awareness of individuals and their relative health outcome. More generally, embodiments recognize that health-conscious individuals are generally more knowledgeable about health and also more healthy as compared to less healthy people (e.g., individuals who suffer from obesity, heart disease, etc.). In fact, embodiments recognize that healthy individuals are significantly more conscientious of maintaining healthy living habits and activities, and with this mindset, such individuals are far more knowledgeable about health than the rest of the population.

With this recognition, embodiments described herein provide a system for gauging how conscientious a given user is with respect to health, based on the user's awareness of information that is specific and health driven embodiments further recognize that such. Such information, which in many cases may qualify as trivia, nevertheless provides a mechanism for delineating those individuals in the population who are in fact conscientious about healthy living habits. Furthermore, embodiments described herein programmatically correlate knowledge of health to physiologic health of individuals amongst a statistically significant sample size of users. Additionally and/or alternatively, other embodiments described herein programmatically correlate knowledge of health to a mortality probability for individuals amongst a statistically significant sample size of users. This knowledge can be used for a variety of purposes, such as pricing life insurance (or premiums).

In order to gauge knowledge, an embodiment of FIG. 1 maintains a library of fact-based assertions on various subjects of human health, such as nutrition, exercise, medicine, etc. In an example of FIG. 1 , the assertions are presented to users in the form of questions, for which responses can provide answers that are either correct or incorrect, and further enable evaluation of knowledge based on whether correct or incorrect answers were given by the users. While examples provide for assertions to be presented to users in the form of questions for purpose of validating their knowledge, other embodiments may use alternative forms of interaction in order to gauge the user's awareness or knowledge of a particular assertion. For example, the user may be provided a statement that is presented as an answer, and the interaction required of the user can be for the user to generate a question that yields the particular answer. In this reverse format, the user's ability to generate the question, combined with a statement as the presented answer, serves as a mechanism for determining whether the user has independent knowledge of the underlying assertion from which the statement was originally presented.

Still further, as described in greater detail, some embodiments utilize a collection of assertions, of which only some have been determined to correlate to physiological health, mental health, mortality rate or underwriting class. The user may have no knowledge of which questions correlate to health and/or mortality rate, or that only some questions have direct correlation to health and/or mortality rate while others are being provided for alternative purposes (e.g. amusement). In some cases, the user may even have no knowledge that some of the assertions for which the user is responding to have any correlation to do with their actual physiological health, mental health, mortality rate or underwriting class. Among other benefits, the use of many questions, in combination with questions that have been determined to correlate to physiological health, mental health, mortality rate or underwriting class preclude some individuals from ‘gaming’ the questions in a manner that masks their true knowledge level and awareness.

In more detail, system 100 includes a user interface 110, question selection logic 120, response logic 130, health scoring logic 140 a, and mortality scoring logic 140 b. The question selection 120 can receive or access questions 127 from a question library 152, and the user interface 110 can present content based on the selected questions 127 to individual users in any one of a variety of computing environments that stimulate the individual to provide purposeful responses that reflect the user's understanding and knowledge for a topic of the question. The questions 127 can vary in their purpose. In one example, question library 152 includes (i) a first set of questions 127 a which have been correlated to physiological or mental health, (ii) a second set of questions 127 b which have not been correlated to physiological or mental health, and (iii) a third set of questions 127 c which have been correlated with mortality rate, but which may serve the alternative purpose of providing trivia, factual information, and/or entertainment. Additionally, the questions of library 152 can be assigned to topics and sub-topics. Still further, the questions of the library 152 can be associated with a difficulty score, based on, for example, a correction rate amongst a control group of persons who answered the question.

When the user initiates a session, the user interface 110 may record a user ID 121 and session information 125. In implementation, the user interface 110 can authenticate the user, and provide credentials 139 for a user profile store 138 in order to obtain profile data 137. The profile data 137 can identify, for example, any one or more of (i) the topic that the user was previously being questioned on, (ii) a topic the user is interested in, (iii) identifiers to questions that the user as previously answered, and/or (iv) a determined knowledge level 135 of the user. With the profile data 137, the user interface 110 can identify parameters or other information for facilitating question selections for the user. In one example, the user interface 110 can use the profile information 137 to specify one or more topical parameters 123 and/or the knowledge level 135 of the user. In turn, the question selection 120 can select questions 127 based on parameters 113, which can be based on, for example, topic parameter 123, knowledge level 135, or user interest and/or preferences.

The profile data 137 can also include user-specific game data 119 (e.g., user's personalizations for gaming, historical performance on games, current game play state, etc.). Additionally, the profile data 137 can include the user's community or social network data 117 (user's personalizations for community or social network application, social network content, etc.). The user-specific game data 119 and community or social network data 117 can, for example, be loaded through the respective functional layers of the user interface 110 when the user initiates a session with a service of system 100.

In addition to using profile data 137 to create parameters 113, system 100 can also use device data 193, which can include indicators of a user's overall health and fitness levels, generated by activity monitoring devices 191 for parameters 113, alone or in combination with profile data 137. Activity monitoring devices 191 include electronic devices (e.g., wearable electronic devices) that can be worn or held by users 11 in order to track data related to the users' activity levels and health parameters.

An activity monitoring device 191 can include resources such as Global Positioning System (GPS), motion sensors, and/or sensors (e.g., heartbeat monitor) to record and track user activity, as well as biometric information of the user in performing such activity. Additionally, the activity monitoring device 191 can include sensors such as an accelerometer or accelerometer set, a gyroscope, a magnetometer, an ambient light sensor, heart rate sensor, temperature sensor and/or other sensors to measure facets of the user's body in performing an activity. The activity monitoring device 191 records activity data 193, which can include statistics like pace, distance, elevation, route history, heartbeat, body temperature and/or other information relating to the user activity. The activity data 193 can include both (i) raw or measured data and (ii) derived or computed data based on measured or raw data and/or user input. Additional examples of device data 193 include heart rate and heart rate trends, steps, distance traveled, floors climbed, calories burned (e.g., derived from distance, pace, and user weight/gender), active minutes, sleep quality, blood sugar, and cholesterol levels, among others.

In some aspects, activity monitoring devices 191 can store their data in a device database 192, which can be managed by a computing platform (e.g., APPLE HEALTHKIT, manufactured by APPLE INC.). Such computing platforms can allow for designated mobile applications to read and write data to the device database 192 based on a set of permissions. For example, the permissions allow a user to choose which applications have access to device data 193 in order to protect privacy and prevent unauthorized access to potentially sensitive information. In some implementations, system 100 may only use device data 193 if a user has specifically opted-in and given permission for the data to be accessed by the system.

The user interface 110 can be used to record responses 129 from individual users. In one implementation, each question 127 can be communicated to the user interface using a sequence in which the answer to the question is also packaged and presented to the user. Some conditional logic may also be provided with the question 127, so that, for example, if the user response is correct, the user is instantly notified and the next question is presented to the user. However, the conditional logic may render an alternative content in response to incorrect user response, specifically a panel or other information item which provides information regarding the actual answer to the question presented. In this way, the user is made more knowledgeable.

The responses 129 can correspond to input that identifies, for example, the user's answer to a particular question. The responses 129 can identify the answer of the user, the question that was answered, and an identifier of the user. In some implementations, each question 127 can further be associated with one or more subject matter topics. Response logic 130 can process the responses 129 from the various users. In one implementation, an initial determination of response logic 130 is whether the question identified with response 129 is pre-associated with a physiological health, mental health, mortality rate or underwriting class correlation, or whether no such pre-association physiological health, mental health, mortality rate or underwriting class correlation exists for the question. In one implementation, the response logic 130 records a corresponding response entry 131 for each response, regardless of whether the question of the response has pre-association with physiological health, mental health, mortality rate or underwriting class. The response entry 131 can reflect whether the answer to the question is correct, as well as the true answer. In some implementations, the response entry 131 further links the question answered to topical designations for the question, as well as calibration or difficulty scoring.

Scoring logic 144 can process the answer of response entry 131 to determine a score value 145 to associate with the particular record entry. The score value 145 can be based in part on the difficulty level of the question, which in some implementations, is provided as a calibration coefficient that is pre-associated with the question. Thus, the mathematical process to tabulate scoring can include factors such as the number of questions the user correctly answered, the number of questions the user incorrectly answered, the difficulty parameter associated with each question, and/or secondary considerations such as the time it took for the user to provide the response and/or whether the user correctly answered the question on the first try. The score value 145 can be stored with the response data store 118.

Additionally, scoring logic 144 can also tally one or more aggregate or overall scores for the user based on a historical record of responses. For example, the response data store 118 can maintain one or more aggregate or ongoing subject matter topical scores (e.g., weight-lifting), as well as an overall score for the user. As described with other examples, scoring logic 144 can be used to develop comparative scoring as between users, based on their overall knowledge, session performance, and/or topical subject matter knowledge.

The response logic 130 can optionally include a knowledge level determination component 134. The knowledge level determination component 134 can determine from the response 129 the knowledge level 135 of the user. Alternatively, the knowledge determination component 134 can determine the knowledge level of the user from the difficulty parameter associated with the question and/or with the score output, as provided by the scoring component 144. The knowledge level determination component 134 can determine an overall knowledge level or a topic-specific knowledge level 135. The determined knowledge level(s) 135 can be stored as part of the user profile 138, so that the knowledge level of the user is communicated to the questions selection logic 120 when the user initiates a session with system 100.

For those selected questions which are identified as having a pre-associated physiological health, mental health, mortality rate or underwriting class correlation, the response logic 130 can provide a corresponding health question record 133 which identifies, for example, the question, the answer provided, and/or whether the question was answered correctly. The health question record 133 can also specify a topic or topics of the question.

According to some embodiments, the question identified with the health question record 133 can be associated with a health parameter value 151 a and/or mortality parameter value 151 b. As described by other examples, the health parameter value 151 a can be determined as part of a correlative model that is developed using a control population in order to provide a quantified correlation to physiological or mental health. The mortality parameter value 151 b can be determined as part of a correlative model that is developed using a control population in order to provide a quantified correlation to a mortality probability of an individual. A health scoring database 150 a can maintain a collection of health parameter values 151 a for individual questions. Additionally and/or alternatively, a mortality scoring database 150 b can maintain a collection of mortality parameter values 151 b for individual questions in one implementation, the health parameter values 151 a reflect a predefined health outcome. In another implementation, the mortality parameter values 151 b similarly reflects a predefined mortality outcome. Multiple health outcomes can be considered, and each question of health question record 133 can be associated with a particular health outcome. By way of examples, the possible health outcomes that have quantifiable correlations to the health parameter values 151 a include (i) health care cost for an individual in a given time period, (ii) number of medical facility visits by an individual in a given time period, (iii) number of prescriptions that the person takes in a given time period, and/or (iv) number of sick days that the person took. Other examples of health outcomes include propensity for cancer (including cancer of different types), heart disease, diabetes, hypertension or other afflictions. The health outcomes can thus be numerical and continuous in nature (e.g., health care cost) or categorical (e.g., number of medical visits, prescriptions, sick days). In some embodiments, the mortality outcomes may be based in whole or in part on the health outcomes.

Accordingly, in one implementation, the health scoring component 140 a utilizes health outcome logic 142 a to generate a health outcome score 165 a that is specific to a particular health outcome definition 155. The health outcome logic 142 a can be implemented as a formula or model, and can take into account parameters that include the health parameter value 151 a determined from an answered question, the number of questions answered, the time of involvement, etc. In one implementation, the health parameter values 151 a that can be combined or tabulated and/or can be determined from identifying the health questions 141 and responses 143 of the user. Based on the question and response the health correlative parameters 151 a are retrieved.

Additionally or alternatively, the mortality scoring component 140 b utilizes mortality outcome logic 142 b to generate a mortality outcome score 165 b. The mortality outcome logic 142 b can be implemented as a formula or model, and can take into account parameters that include the mortality parameter value 151 b determined from an answered question, the number of questions answered, the time of involvement, etc. In one implementation, the mortality parameter values 151 b can be combined or tabulated and/or can be determined from identifying the health questions 141 and responses 143 of the user. Based on the question and response the mortality correlative parameters 151 b are retrieved. In an embodiment, the health scoring component 140 a uses the health correlation parameter 151 a, as well as the question 141 and response 143 to predict the health outcome 165 a of the user. In determining the health outcome, the health scoring component 140 a can use a model or formula to determine the health output score 165 a. For example, the health scoring component 140 a can map the user's input to a health score output which is then predictive for the user. The model used by the scoring component 140 a to predict the health outcome score 165 a of the user can be the same model which determines the correlation of questions to the particular health outcome definition. Examples of such models are provided with FIG. 2 .

Additionally, the mortality scoring component 140 b uses the mortality correlation parameter 151 b, as well as the question 141 and response 143 to predict the mortality outcome 165 b of the user. In determining the mortality outcome, the mortality scoring component 140 b can use a model or formula to determine the mortality output score 165 b. For example, the mortality scoring component 140 b can map the user's input to a mortality score output which is then predictive for the user. The health outcome score 165 a and/or the mortality outcome score 165 b can be generated and stored as part of the user health data store 160. Additionally, the health outcome score 165 a can be specific to a particular health outcome, and the type of value it reflects can be specific to the health outcome type. For example, one implementation provides that for a health outcome that reflects health care cost for the individual, the health outcome score 165 a can be a numeric indication of a specific cost or range of costs for the individual. The health outcome score 165 a for the number of medical facility visits, on the other hand, can be reflected by a category or level (e.g., 1 to 5 depending on amount).

In one implementation, the user health data store 160 is maintained logically or physically separate from the question response data store 118 in order to preclude its viewability to users of the system 100. Each user can include a profile of health outcome scores with the user health data store 160, with individual user profiles 141 which include scores for multiple different health outcomes. In some variations, a combined score or category may also be given to individual users as part of their health profile.

As described with other embodiments, the health outcome score(s) 165 a and/or mortality outcome scores 165 b of the user can be made available for health services, such as health insurance services. For example, the premium, deductible or scope of coverage provided as part of a health insurance package for a user can be determined from the health outcome score(s) 165 a and/or mortality outcome score 165 b. As another feature, health outcome score(s) 165 a and/or mortality outcome score(s) 165 b of the user can be used to determine if the user should receive a discount for health insurance, or alternatively receive an added benefit from health related services that are provided (or are to be provided) to the user.

According to one embodiment, a health service 190 sub-system can utilize the health outcome scores 165 a and/or mortality outcome scores 165 b provided in the user health database 160 to determine designations, qualifications or service level, in connection with a health-related service. Examples of health related services 190 include health insurance, life insurance, health service plans, memberships in health related facilities (e.g., health spas, medical office), informational services (e.g., magazine or journal subscriptions, electronic news). The benefit that can be provided to the user includes the service itself, or alternatively a designation of health for use with such a service. For example, the user's predicted level of health can be determined by the health outcome score(s) 165 a, and this can result in an overall health outcome determination (e.g., a ranking or classification), which in turn can be used to receive a discount for health related services (e.g., discount on health or life insurance premium, expanded coverage, etc.). An example of health service sub-system is provided with an example of FIG. 6B.

In some implementations, the user interface 110 of system 100 can include various layers or functional components for enhancing the interactivity level of the user. In one implementation, the user interface 110 includes a gamification layer 112 and a community social network layer 114. The gamification layer 112 includes logic, data, and content (collectively “game data 103”) for implementing a competitive environment for which the individual is to supply answers for questions 127. The game data 103 can be generated a gaming engine 115, which can further personalize the gaming environment for the specific user. For example, the user identifier 121 can be used by a gaming engine 115 to generate user-specific game data 103. The game data 103 can, for example, include a competitive environment that is based on the knowledge level of the user and/or topical interests of the user. An implementation that utilizes a gamification layer 112 is described with FIG. 7A. The gamification layer 112 can determine awards or credentials (e.g., skill level badges) for the user based on their performance. By way of example, the questions 127 presented through the user interface 110 can be associated with a score value that accounts for difficulty (which may be determined from a calibration process, as detailed below), response time, handicaps (e.g., the age of the user), etc.

The community social network layer 114 can operate using community data 117, which can be generated from a community/social network service 116. The community/social network service 116 can, for example, provide user-specific community (or social network) data based on the user identifier 121. The community data 117 can provide content (e.g., user's health interest or knowledge specialties) that is provided as part of the community social network layer 114.

The health parameter value 151 a and mortality parameter value 151 b represent a correlative and quantified measure as between human health and knowledge of a particular assertion. The granularity of the health parameter value 151 a and/or mortality parameter value 151 b is applied to a question as answered from an individual, but the determination of the value can be based on a correlative model applied to a control population of users. The control population of users include those individuals who, for example, voluntarily provide real-world information about themselves, and more specifically, actual health outcomes in a recent duration of time. The control population of user may also include those individuals who are deemed to be deceased at a particular point in time. Activities of those individuals can be evaluated retroactively to determine whether a mortality correlation exists (as well as the degree of correlation) with respect to activities. By way of example, the activities can include participation in health quizzes and tutorials. The source for data in the mortality control group can include online social media sites, and obituary services.

In more detail, system 100 can include a question analysis sub-system 170 that includes functionality for determining correlations between knowledge of individual questions and actual health outcomes and/or mortality outcomes. The sub-system 170 can implement and develop one or more correlative models 172, which can analyze input questions 171 for the purpose of determining correlations to health outcomes and/or mortality outcomes. In particular, the correlative models can be implemented for purpose of determining health parameter values 149 a and/or mortality parameter values 149 b that statistically reflect a correlation as between knowledge of individuals in the control population (shown with the control population database 180) for particular question and the respective health and/or mortality outcomes for those individuals who answered the question (either correctly or incorrectly, depending on implementation). The health correlative values 151 a and/or the mortality correlative values 151 b can be specific to individual questions or cluster of questions. In one implementation, different correlative models 172 can be used for different types of health outcomes. Different correlative models may compare a predicted value with actual (or real-world) data provided for individuals (shown as real-world information 175). The real-world information 175 may also include actual (e.g., real-world) data from social media sites and/or obituaries. An example of question analysis sub-system is described in more detail with an example of FIG. 2 .

In addition, the control population database 180 may include a population of individuals that make up a control group that can be used to compare a true health outcome and/or mortality outcome to expected outcomes. The expected outcomes can be a function of the health parameter values 149 a and/or the mortality parameter values 149 b that determines correlations between knowledge of individual questions and actual health outcomes and/or mortality outcomes. In an embodiment, the control group may be dynamic, such that individuals can be added to the control population database 180 continuously over time through voluntary opt-in features or invitation. Additionally and/or alternatively, the control population database 180 may store individuals who have been added, including individuals who have been added in the past (e.g., months, years, or decades ago). Accordingly, some individuals who are included in the control population database 180 for a long period of time may have, since being added, become deceased. These deceased individuals can provide real-world information 175 about actual mortality outcomes. An example of providing real-world mortality information to the system 100 is described in more detail with an example of FIG. 10 . As more individuals are added to the control population database 180, the correlation(s) for health and/or mortality may be made more valid or certain. While numerous examples provide for use of health and/or mortality correlative scores, other embodiments can also generate recommendations to users based on their overall knowledge level, as determined by, for example, the user's score, or topic-specific scores. A response analysis 164 can retrieve scores 145 from the response database 118, for example, and generate recommendations, content or other output based on the user scores. An example of response analysis 164 is illustrated with FIG. 7B, and accompanying examples thereof.

As an addition or alternative, the community social network layer 114 can provide forums such as message boards, ask an expert, or topical walls for shared information and experiences. In one implementation, credentials that the user earns through the gamification layer 112 are carried onto the social environment of the community social network layer 114. For example, an ‘expert level’ user may have credence when responding to questions of others, even to a point where the user can request payment or other consideration for providing answers or information to other users.

FIG. 2 illustrates an analysis system, according to an embodiment. In particular, FIG. 2 illustrates an analysis system 200 for analyzing questions (or other forms of assertions) for purpose of determining whether knowledge of the underlying assertions by subjects can be correlated to physiological or mental health of the subjects. According to some embodiments, individual questions, or alternatively groups of questions, can be correlated to a quantifiable metric that statistically relates a subject's knowledge (or lack of knowledge) for an underlying assertion to a likelihood of a particular health outcome. The system 200 can be implemented as, for example, a sub-system of a physiological/mental predictive system 100, such as shown with an example of FIG. 1 .

In more detail, system 200 includes a question intake interface 210, a fielder 220, a calibration component 230, and a correlative model implementation component 250. A question interface can receive questions 209 through, for example, a manual interface (e.g., experts generate questions based on health assertions). The questions 209 can be manually associated with one or more topics relating to human health, such as topics relating to nutrition or exercise, or specific medical conditions. The granularity of the topics 211 can be determined by implementation. A question store 215 can be used to store a question 209 for processing as the question is calibrated and/or correlated to human health.

The fielder 220 includes functionality to distribute the questions 209 to a control population of users through a population interface 222. For example, the fielder 220 can issue questions using the user interface 110 of an example system of FIG. 1 . For example, with further reference to an example of FIG. 1 , questions 209 can be issued through gameplay of user interface 110, and responses from various users can be recorded. Some users, however, can be designated as belonging to the control group. These users can correspond to individuals for which data corresponding to ground truth data exists. For example, many users can be given an opportunity to volunteer real-world health information. Such users can be asked questions such as “how many doctor visits did you have last year” or “how many sick days did you have last year.” Still further, some information like the user's health insurance cost can be obtained from a source such as the insurance companies. Accordingly, in one example such as shown by FIG. 1 , members of the control group can supply responses 213 to questions 209, presented through a game. At a separate time, either before or after the questions 209 is presented to the subject, the subject can also be given the choice to provide actual data, shown as true user data 241. The true user data 241 can represent an actual health outcome of a subject providing the response 213. The true user data 241 can include information manually supplied by the subject, as well as information provided by, for example, an insurance carrier of the subject. Each response 213 from one of the subjects of the control population (e.g., those users of system 100 who opt-in to provide information) can be linked to the question and to the identifier 205 of the subject. Additionally, the true user data 241 can be linked to the user identifier 205 of the subject providing the response.

In addition, true user data 241 can be supplemented or replaced with information gathered by activity monitoring devices 225 in order to create more accurate control data. Activity monitoring devices 225 can provide health data 226 from sensors, such as heart rate and heart rate trends, calories burned, active minutes, sleep quality, blood sugar, or cholesterol levels. Location data 227 can also be provided and includes where a user is located based on GPS data, which can be used in conjunction with other databases to determine, for example, if a user is in a restaurant, grocery store, etc. Furthermore, time data 228 can be used to track a user's schedule. In addition, a user can also choose questions to send to a friend through their activity monitoring devices 225 as friend data 229.

In some embodiments, some or all of these data gathered from activity monitoring devices 225 can be used by fielder 220 to choose which questions 209 are presented to a user. For example, if health data 226 shows that a user has high blood pressure, questions relating to how to lower blood pressure can be chosen. If the user is shown to have poor sleep quality, questions about tips to get better sleep can be chosen. If the user has just finished a workout, questions about post-workout recovery can be chosen. If a user is determined to be a new runner, questions about basic running knowledge can be chosen, whereas if a user is an advanced runner, more advanced questions can be chosen instead.

Location data 227 and time data 228 can also be used by fielder 220 to interpret a user's schedule and choose appropriate schedule-related questions. For example, if the data show that a user commutes via a long subway ride every weekday, questions about exercise ideas for long commuters can be shown. If a user is detected in a restaurant, questions regarding healthy food choices can be shown, and if a user is in a grocery store, questions about vegetables, organic food, and nutrition can be shown.

The calibration component 230 can analyze the questions 209 under process to determine a difficulty level 265 of the question. For example, the calibration component 230 can query 231 the intake store 215 for a tally of the number of responses which were correct and incorrect. The percentage of individuals who correctly answer a question can provide a basis for determining a difficulty level of the question. The difficulty level 265 can be stored with the question for subsequent use.

The correlation model 250 operates to determine a correlation between knowledge by a subject for an underlying assertion of a question and the subject's health. In one implementation, the correlation model 250 implements one or multiple models for purpose of determining different parametric values that statistically correlate to different health outcome definitions (e.g., amount of healthcare or healthcare cost an individual requires, the number of medical facility visits, propensity for heart disease, cancer, hypertension or diabetes, etc.). The correlation model 250 can receive, as model input 255, (i) a question identifier 261, (ii) identification of a set of individuals in the control group who answered the question 209, including identification of the answer each person provided to the question 209, and (iii) true user data 241 for each person in the set of individuals that answered the question. The particular model selected compares an expected result to a true result by (i) assigning the person to an expected result, corresponding to a particular health parameter value, based on their answer to a question, then (ii) using the true user data 241 to compare a true health outcome (reflecting real-world data of the individual supplying the answer) to the expected result.

The expected result can initially start as a hypothetical or neutral value, indicating a likelihood that a given person has or does not have a particular health outcome based on the answer the person provided to the question. The expected result can further include different values depending on whether the user provided a correct answer or incorrect answer, as well as which incorrect answer the user provided. The initial correlation can correspond to a coefficient (e.g., a value between 0 and 1) that is set by, for example, an expectation as to whether the underlying assertion of the question is information that is indicative of health-conscious behavior (e.g., rubbing one's eyes can make a person susceptible to common cold) or information that is indicative of poor health-conscious behavior (e.g., specific nutritional information about a donut). From the initial value, the correlation can become positive, negative or made neutral based on the expected/actual comparison for persons in the set. As more individuals are added to the set, the correlation can be made more valid or certain. The determined correlation from the correlation model 250 can be identified as correlative health parameter 251. The correlative health parameter 251 can be specific to a particular health outcome 253. The correlative health parameter 251 can, for example, correspond to a parametric value, such as a weight or coefficient, which can be aggregated, modeled and/or combined with other parametric values to make a health outcome determination.

The particular model 255 implemented by correlation model 250 can depend on the nature of the health outcome that the assertion is to apply to. For a health outcome definition in which the health parameter value is continuous (e.g., monetary cost for health care in a given period, weight or body mass index), a linear regression model can be used. Some health outcome definitions can utilize health parameter values which are tiered or categorical. For example, the number of medical facility visits can be defined into tiered values, such as: 0=no medical facility visits, 1=1-2 medical facility visits in a year, 2=3-5 medical facility visits in a year, or 4=5 or more medical facility visits in a year. Similar tiered values can be used for health outcomes such as sick days. For such health outcomes, an ordinal logistic regression model can be used. In variations, a multinomial or polynomial model can be used for tiered categories, particularly those health outcomes which define tiers which are not naturally ordered. Each question can be assigned to a particular health outcome, so that the health parameter value is specific to the determination of the health outcome.

Numerous other machine-learning models can be used in both developing correlative health parameters, and determining health outcomes based on correlative health parameters. By way of example, such machine-learning models can include random forest, neural network and/or gradient boosting models.

In some embodiments, the determination of the health parameter values 251 can be tuned to reflect determinations that are for use with a model in which no user-specific information is known. In one implementation, the control population can be associated with classification parameters, such as age group (e.g., over 50, under 50), gender, weight, race, geographic location or setting, and/or presence of certain medical conditions such as diabetes. An individual question can be associated with multiple correlative health parameter values 251, including health parameter values that reflect the general control population, as well as a health parameter value that is specific to a class or sub-class (e.g., females over 50).

According to some embodiments, a combination of question and correlative health values 251 can map to one of multiple possible health outcomes. Thus, in one implementation, a question can have a correlative health value as it applies to a single health outcome.

Other implementations provide tor the determination of health parameter values 251 which are correlative to health of a user based on a model in which a classification (e.g., gender or age) or set of classifications (e.g., gender and age) are known about the person answering the question. Depending on implementation, the classifications of users can include (i) unknown users, for which no information is known, (ii) users for which some basic health-relevant characteristic is known, such as age, gender, or combination thereof, (iii) users for which multiple relevant facets of health is known, such as their weight and/or height, as well as, as gender and age. One implementation provides for the determination of correlative health parameters 251 which are determined specific for different classifications of the user, based on applying models as described to segments of the control population which have the relevant classification. Thus, in some variations, the correlative health parameter values 251 can be made specific to specific classes of persons, so that the evaluation of health for the user is made in reference to the user's class. For example, in some embodiments, the questions can be fielded for individuals who categorize themselves by gender, age, weight, and/or presence of certain medical conditions such as diabetes.

System 200 can be implemented on a control group that is dynamic, meaning individuals can be added to the control group continuously over time. As mentioned, a larger control group can provide more valid results. In an interactive gaming environment, such as described with an example of FIG. 1 , additional persons can be added to the control group continuously through invitation or opt-in features. For example, the user-interface 110 can prompt individuals to volunteer for questions that reflect actual medically relevant information. This mechanism can provide a way to expand the control group with the addition of users for whom true user data 241 can be provided. The control group can also be managed based on criteria, such as gender and age, so that it accurately reflects a desired population segment.

With the determination of the health parameter values 251, the questions can be deemed processed, in which case the questions can be included in a library or collection of questions and marked as being correlative to health. In one implementation, a library build process 260 links processed questions 259 with the question identifier 261, topical identifier, the difficulty level 265 and the correlative health parameter 251 (or multiple values). The difficulty level 265 can be used to determine which individuals receive the question based on user level.

While an example of FIG. 2 provides for processing of questions which are deemed correlative to health, a fielding and calibration process can be used to determine difficulty of all questions, including those questions which have no determined correlation to health. For example, any question can be associated with the topic 211 and fielded to the control population as described, and further evaluated for difficulty level 265 based on, for example, the percentage of individuals of the control group who correctly answered the question.

FIG. 3 illustrates an example of a data structure that can be developed to link a question with a health outcome and a topic, according to one or more embodiments. While an example of FIG. 3 illustrates the data structure 300 as being logically integrated, variations can provide for distributed data structures which associate or link parameters as described. With reference to an example of FIG. 1 , the data structure 300 of an example of FIG. 3 can, for example, be provided with the question library 152, and include information provided with the health scoring database 150 a.

In more detail, data structure 300 associates individual questions by question identifier 301 to one of multiple possible correlative health parameters 303, and one or more topics 305. Other information or parameters that can be conveyed with the data structure 300 include a difficulty level, which can be determined, for example, through an output of the calibration component 230 (see FIG. 2 ). For a given implementation, the correlative health parameter can relate to a particular health outcome. Multiple health outcomes can be defined for a future time interval, including health care cost, medical facility visits, sick days, and number of prescriptions. Other examples of health outcomes include blood sugar level, weight or body fat (e.g., BMI), cholesterol level, depression or anxiety disorder, and/or longevity. In one embodiment, each question associated to only one health outcome, and is further assigned a correlative health parameter value that reflects a correlative measure between knowledge of the underlying assertion and a corresponding health outcome. In one implementation, a system of FIG. 2 determines health parameter values for each defined health outcome, and the health parameter value selected for a question is that which has the strongest correlation. If no correlative health determination has been made for a question, then the health parameter values for such questions can be shown as null.

As further shown by an example of FIG. 3 , each question can be linked with multiple topics based on, for example, manual input. The determined difficulty can also be expressed as a parameter, such as a number between 0 and 1. The difficulty level can be independent of the topic assignment for the question-thus, meaning the difficulty level of a question can be provided as being the same regardless of the assigned topic being considered.

Methodology

FIG. 4 illustrates an example method for predicting a health outcome of a user based in part on whether a user has independent knowledge of an assertion relating to health. FIG. 5 illustrates an example method for predicting a health outcome of a user based on a knowledge profile of a user. In describing example methods of FIG. 4 and FIG. 5 , reference may be made to elements of FIG. 1 , FIG. 2 or FIG. 3 for purpose of illustrating a suitable component for performing a step or sub-step being described.

With reference to an example of FIG. 4 , a collection of assertions relating to human health can be stored and processed for use with a population of users (410). In one implementation, the assertions can be formatted as questions for which the answer from the user indicates whether the user has knowledge of the assertion (412).

For the control population, a health parameter value is determined for individuals of the control population (420). The health parameter value can reference actual or real-world data which serves as an indicator of physiological or mental health of a user. In one implementation, the determination of the health parameter value can be based on input of a user. For example, in an interactive gaming environment of FIG. 1 , some users can opt-in to provide requested health-specific input, such as the number of sick days taken in the prior month or year. In some embodiments, the health parameter value is based on a defined health outcome (422), or combinations of health outcomes. By way of example, the health outcome can correspond to an estimated health care cost for an individual (424), a number of medical center visits for an individual in a given duration of time (425), a number of prescriptions for the individual in the given time frame (426), and a number of sick days an individual incurred in the given duration of time (428).

For each assertion, a correlative health parameter is determined (430). Generally, the correlative health parameter corresponds to a parametric measure that quantifiably links knowledge of an assertion to human health. The health parameter value 151 a (FIG. 1 ), 251 (FIG. 2 ), as described with other examples, provides an example based on use of a control group (432).

The establishment of questions with associated correlative health parameters can be done through implementation of a model, with ground truth data provided by select users from a larger user base of respondents. Once the correlative health parameters are established for individual questions, the questions can be fielded to the user base. The responses from the user can be used to determine the user's independent knowledge level of a particular assertion (440).

The correlative health parameters for the individual questions answered by the user can be determined and modeled into a value for a particular health outcome (450). For each user, the correlative health parameters of the answered questions pertaining to a particular health outcome can serve as inputs in order to determine a predicted health outcome for the user (460). Multiple health outcomes can be determined in this manner.

With reference to FIG. 5 , a knowledge profile of a user can be determined, relating to a particular health outcome (510). The knowledge profile can reflect answers to individual questions, or answers to clusters or groups of questions. The knowledge profile can be determined based on a selected definition. In one implementation, the knowledge profile is specific to a question, and reflects whether a user correctly answer the question. In a variation, the knowledge profile is specific to a question, and reflects which question the user answered. Still further, the knowledge profile can reflect the user's answers in aggregate form, such as in a cluster of questions (e.g., 3 to 10 questions), reflecting facets such as the number of questions the user correctly answered in the cluster, or the number of answers provided which were deemed more wrong than others.

A facet of the knowledge profile can be compared to corresponding facets of knowledge profiles from individuals of a control group (520). In one implementation, the user's answer to a particular set of questions can be individually compared to an answer to the same set of questions from one or multiple persons of the control group. In variations, the user's answer to a cluster of questions can be compared to answers provided by a subset of the control group for the same cluster of questions, with the comparison being made for the cluster of questions as a whole. Still further, the user's answers can be compared to answers provided by a subset of the control group which provided the same exact answers for the cluster of questions.

A health outcome can be determined for individuals of the control group (530). As mentioned with other examples, the health outcome can be defined as a healthy living style characteristic that is indicative of human health. The health outcome that is determined for a person of the control group can reflect real-world information about that person (532). In one implementation, individuals of the control group can volunteer their personal health outcome information (534). For example, the information can be provided in exchange for some benefit to the person of the control group. In other examples, personal health outcome information for persons in the control group can be determined using data from activity monitoring devices. In variations, the health outcomes information for persons of the control group can be determined from sources such as health care or insurance providers (536).

The health outcome of a user can be predicted based in part on a correlation between the health outcomes of individuals in the control population and the compared facets of the knowledge profile between the user and persons of the control group (540). Thus for example, a user's answer to individual questions can be compared to the answers provided for the same questions by those members of the control group. As an addition or alternative, a user's answers to a cluster of questions can be compared to answers provided to the same cluster of questions for individuals of the control group, with, for example, the comparison being based on matching the user with a subset of persons of the control group based on a percentage of correct or incorrect answers provided.

Health Service Methodology and Sub-System

FIG. 6A illustrates an example method for providing a health related service to a user based on a knowledge-predicted health outcome for a user. In describing example method of FIG. 6A, reference may be made to elements of FIG. 1 , FIG. 2 or FIG. 3 for purpose of illustrating a suitable component for performing a step or sub-step being described.

With reference to FIG. 6A, a health knowledge profile is determined from each of multiple users (610) with regard to assertions relating to health (e.g., physiological or mental health). As mentioned with other examples, the health knowledge profile can reflect individual answers to questions, those questions which were answered correctly or incorrectly, specific answers provided to specific questions (e.g., such as incorrect answers), and/or percentages of questions answered from a defined cluster of questions.

Additionally, as mentioned with other examples, a value of a health correlation parameter can be determined as between the user and a subset of persons in the control group (620). With reference to an example of FIG. 1 , the health value parameter 151 a can, for example, be determined by the health scoring component 140 a. In determining the health correlation parameter, a given facet of the users' knowledge profile can be compared to that of relevant persons in the control group (622). By way of example, the comparison can be on a question by question basis, or alternatively, on a cluster basis (e.g., compare set of 5 answers, etc.). Actual health outcomes can be known for members of the control group, and the identified correlative health parameters can be based in part on the known health parameters of individuals in the control group. The correlative health parameter can thus be pre-determined for the control group, and based on real-world information about members of the control group.

Based on the correlation values, a health outcome determination is provided for the user (630). As shown with an example of FIG. 3 , the correlation values can be specific to pre-determined health outcomes. Further with reference to an example of FIG. 1 , given a set of health parameter values 151 a for a particular health outcome, the health scoring component 140 a can make a health outcome determination. The determination of the health outcome can be in the form of a score, so that it gives a relative measure of the particular health outcome as compared to other individuals in the general population. The health outcome determination can correspond to a health outcome score 165 a, or alternatively, to a combination of health outcome scores. For example, multiple health outcome scores can be determined for the user, and the scores can be combined to form an aggregate health outcome determination.

Based on the health outcome determination, a health service benefit can be provided to the user (640). The service or designation can be one made for a set value, wherein the service or designation is associated with a true per-user cost that is not equal to the set value, but which is variable and set to increases over time when individual users in the subset suffer negative health consequences as a result of a naturally progressing medical condition.

The health service benefit can correspond to a variety of direct and indirect service related benefits. In one implementation, those users with a health outcome determination that exceeds a particular threshold can receive a designation (642). The designation can correspond to a service or credential provided to only select users of, for example, a network service provided with system 100 (644). For example, those users which receive a health outcome determination that places them within the top 10 percentile of all users may receive a certification, which in turn enables them to receiving discounts with their healthcare provider, health insurance, or related health service activities (e.g., discount with nutrition store, athletic gym membership, life insurance, etc.). Alternatively, the designation can entitle the subset of users to receive a service, such as primary health insurance, supplemental accidental insurance, life insurance, or other membership service (whether health related or not).

In variations, the health outcome determination provides a basis for predicting a user's health, and this basis can in turn be used to determine health related services for the user (646). For example, health insurance, life insurance, and/or accidental health insurance can be provided to the user with scope and cost determined by the health outcome determination. For example, the cost of the premium or deductible to the individual user can be based on the health outcome determination (648). By way of example, an insurance service can be provided to users of system 100, and those users with better health outcome determinations can be provided discounts to their premiums or deductibles, or alternatively given greater scope of coverage as compared to counterparts users who have lesser health outcome determinations.

FIG. 6B illustrates a health service sub-system 680, according to an embodiment. A health service sub-system 680 can be implemented with or as part of, for example, system 100. In variations, the health service sub-system 680 can be provided as a separate system which interfaces with the system 100. Additionally, the health service sub-system 680 provides an example of a system on which an example of FIG. 6 can be implemented.

With reference to FIG. 6B, a health service sub-system 680 includes a system interface 682, a customer data store 684, and service determination logic 686. The health service sub-system 680 can also include a service customer interface 688, such as a web page or application page, which a service customer accesses to provide input for defining the health service offered, as well specific logic or parameters for the service determination logic 686. The service customer input 685 can, for example, include text data definition of the service offered (e.g., terms of health or life insurance), as well a supplemental content for viewing by users of system 100. This input can be stored in the service data store 684.

In some variations, the service customer input 685 can further input parameters 683 and other logic (e.g., rules) for the service determination logic 686. The parameters 683 and rules can, for example, including definition of the qualifications needed for users to (i) receive the service, (ii) receive a particular facet or tier of the service, and/or (iii) receive the service or tier according to a particular price structure. For example, the service can include tiers of benefits, or multi-tiered cost structure, and each tier can be provided to users based on qualifications, such as one or more of (i) a threshold health outcome score or set of scores, (ii) a threshold combination of health outcome score, and/or (iii) other health outcome determination.

The system interface 682 can interface with the user health database 680 in order to determine the health outcome scores 689 of a given user or user-base. In a variation, the system interface 682 can communicate with a push or trigger component on the system 100 which in turn retrieves and pushes specified health outcome scores to the system interface 682. In some embodiments, end-users are precluded from handling health outcome data. The output of health determination logic 686 can correspond to a notification 691, which can specify the results of the health determination logic 686. These results can be communicated to either the user or to a provider of the health service benefit.

Game Play

Numerous embodiments described use of game play and logic as a mechanism to increase use response and participation. More user response and participation can have numerous benefits, including (i) increasing the size of the control group, by finding more qualified volunteers who are willing to provide real-world health information for purpose of developing health correlations to questions, (ii) more predictive correlations based on larger statistical sample, and (iii) data points from users, enabling better prediction of individual user health. Additionally, the use of game logic provides a mechanism to hide health correlative questions from public inspection, thereby precluding users from “gaming” the questions (e.g., studying) for purpose of receiving a good health score.

FIG. 7A illustrates an example method for providing a game-based environment in which user responses enable prediction of health outcomes for individual users. In describing an example method of FIG. 7A, reference may be made to elements of FIG. 1 , FIG. 2 or FIG. 3 for purpose of illustrating a suitable component for performing a step or sub-step being described.

With reference to an example of FIG. 7A, a set of questions can be stored, were at least some of the questions are based on assertions that are core relative to health (702). For example, questions can be stored in the question library 152, after being processed using a system such as described with an example of FIG. 2 . The stored questions can include both (i) health correlative questions, which are used in determining a health outcome score or determination for the user (704); and (ii) non-health correlative questions. While the latter questions may pertain to health, those questions have either not been determined to be correlative or health, or those questions have little relevance to awareness for health, and thus correlative to actual human health (706). As mentioned with other examples, a gaming environment can be implemented in which the questions are provided as trivia, so that users receive entertainment benefit from participating in answering questions.

Still further, as described with other examples, the health correlative questions can be processed to determine a health correlative parameter (710). For example, question analysis subsystem 200 can be used to determine a health correlative parameter 151 a for a given question. Still further, as described with other examples, the health correlative parameter can be based on persons in the control population who have knowledge (or knowledge deficit thereof) of an assertion underlying the particular question (712).

In order to encourage participation and development of accurate health outcome scores and determinations, a gaming environment can be established in which users are asked questions in a competitive or semi-competitive context (720). An example of a gaming environment is shown with environments depicted through interfaces of FIG. 8A through 8H.

The user responses to trivia questions are recorded, with those responses including both scores related to health correlative questions (730) and scores related to all questions (or alternatively to non-health correlative scores) (732). As described with an example of FIG. 6 , the health correlative questions can be scored for purpose of determining health services to the user (740). This score may be hidden or unknown to the user, and determine independently of the overall gaming score.

Conversely, the overall gaming score can be published in a social or gaming environment, to provide the user with credentials in the community of the service provided through system 100 (742). For example, the user can use the latter gaming score to achieve credentials that give the user authority on message board discussions, and question and answer forums of the community platform.

In some variations, the gaming score can also provide a mechanism to provide health base recommendations to the user (744). For example, the user's knowledge base can be evaluated based on topical subjects, and the user's deficiency or strengths respect to specific topics of health can be used to infer physiological or mental information about the user.

FIG. 7B illustrates a knowledge-based recommendation engine, according to one or more embodiments. With reference to FIG. 1 and FIG. 7B, for example, the response analysis component 164 can include recommendation engine 780. The recommendation engine 780 can use information about the user's knowledge in order to generate recommendations 785, which can include content that communicates to the user specific actions, lifestyle choices, or areas of growth (for knowledge or lifestyle), for purpose of growth.

In one implementation, the recommendations 785 can be based on the determinations of the user's strength or weakness with regards to specific topics of health. The recommendation engine 780 can include processes 782 which retrieve the user's topical scores 781, and then correlate the topical scores with recommendation logic 790. The recommendation logic 790 can include rules 791, 793 for selecting recommendations for the user based on different topical scores and criteria. For example, the recommendation logic 790 can include rules for suggesting recommendations to users for specific topics when the user's score for the topic is below a threshold. By way of example, a topic can be defined for cardiac health, and anytime a user's topical score for cardiac health is below a threshold, a set of recommendations 785 for improving the user's cardiac health can be generated and communicated to the user. Likewise, if the user's knowledge is strong in a particular topic, that can also be interpreted as interest, and the recommendation logic 790 can utilize the score to suggest recommendations that are of an advanced level. For example, if the user scores high in the topic of weight lifting, then the recommendation provided to the user can include specific techniques or recommendations based on questions that have the highest difficulty level (as determined from, for example, a calibration component 230 of FIG. 2 ).

In some implementations, activity monitoring devices 770 can provide device data 774, which can include indicators of a user's overall health and fitness levels, to the recommendation logic 790. These devices can include GPS receivers to record statistics like pace, distance, elevation, route history and workout summaries. In addition, they can include sensors such as accelerometers, a gyroscope, a compass, an ambient light sensor, heart rate sensor, among other features capable of tracking and recording health and fitness parameters. Examples of device data 774 include heart rate and heart rate trends, steps, distance traveled, floors climbed, calories burned, active minutes, sleep quality, blood sugar, and cholesterol levels, among others. Recommendation logic 790 can then use device 774, alone or in combination with rules 791,793 and topical scores 781, in order to create the recommendation set 785. For example, if topical scores 781 show that a user has poor knowledge of cholesterol but device data 774 indicates that the user's cholesterol levels are satisfactory, recommendation logic 790 may choose not to recommend cholesterol-related questions.

In a variation, the set of recommendations 785 generated for any one topic can be associated linked with questions or sub-topics of questions. A recommendation filter 792 can filter the recommendations 785, so as to weed out those recommendations the user likely knows based on their correctly answered questions.

Still further, the recommendation logic 790 can include combination rules, which select recommendations 785 for the user based on criterion provided by the user's topical score in two or more topics. The combination rules can identify subject matter relevancy between topics, so that the user's knowledge of one topic will benefit another or vice versa. In one implementation, when the user's topical score of one topic exceeds a threshold, and the topical score of another topic is below a threshold, then the recommendation may be provided that assumes user activity or interest in one topic to assist the user's knowledge or lifestyle with regards to the second topic. For example, the user may have scored high in the topic of weight-lifting, but scored low in nutrition or sleep. The recommendation provided to the user may identify the recommended hours for the user to sleep in order to add muscle mass.

By way of another example, if the user is strong on a subject such as weight training, but poor in nutrition, then the recommendation engine can suggest (i) that the user develop his knowledge on nutrition, (ii) identify nutritional information related to training in order to provide recommendations. Recommendations can include, for example, what the user should eat when training, how such nutritional intake can affect performance in training, recommendations for the user to confirm with a nutritionist, and expected results that can be achieved through proper diet and weight training. Such an example illustrates recommendations that can be made based on the user being strong in his or her knowledge base for one topic and weak in another topic. In such scenarios, the relationship between the two topics can be determined in order to generate programmatically actions and subtopics of learning which may be of interest or benefit to the user.

Similar recommendations can be determined and linked to user's topical scores based on different threshold determinations. In one implementation, if the user scores low on two topics related by subject matter, the user's recommendation may be selected on the assumption that the user suffers from health consequences related to a physiological or mental problem related to the topics.

Still further, analysis of the topical determinations can also be used to infer characteristics about the respondents, without any mathematical correlation being made to the control population. For example, an individual who scores poorly in both nutrition and exercise can be inferred to be obese, potentially diabetic, and/or suffer from other health related issues such as depression. Based on such analysis, the recommendation engine can suggest areas of growth for the user's knowledge. The recommendation engine 780 can also provide recommended actions, such as publishing a diet to the user for weight loss, suggesting the user visits a psychiatrist (on a sound assumption that the user is depressed), suggesting the user sees a nutritionist and/or personal trainer (on the side assumption that the user is overweight), or recommend that the user have his blood sugar checked for diabetes and or high cholesterol. Such actions can follow when the user scores poorly on knowledge in topics that have synergy or relation to one another when considered for physiological or mental health.

FIG. 7C illustrates an example method for choosing questions to provide to a user based on data retrieved from activity monitoring devices. In describing an example method of FIG. 7A, reference may be made to elements of FIG. 1 , FIG. 2 or FIG. 3 for purpose of illustrating a suitable component for performing a step or sub-step being described.

With reference to an example of FIG. 7A, a set of questions can be stored, were at least some of the questions are based on assertions that are core relative to health (750). For example, questions can be stored in the question library 152, after being processed using a system such as described with an example of FIG. 2 . The stored questions can include both (i) health correlative questions, which are used in determining a health outcome score or determination for the user (752); and (ii) non-health correlative questions. While the latter questions may pertain to health, those questions have either not been determined to be correlative for health, or those questions have little relevance to awareness for health, and thus correlative to actual human health (754). As mentioned with other examples, a gaming environment can be implemented in which the questions are provided as trivia, so that users receive entertainment benefit from participating in answering questions.

Still further, as described with other examples, the health correlative questions can be processed to determine a health correlative parameter (755). For example, question analysis subsystem 200 can be used to determine a health correlative parameter 151 a for a given question. Still further, as described with other examples, the health correlative parameter can be based on persons in the control population who have knowledge (or knowledge deficit thereof) of an assertion underlying the particular question (760).

In some aspects, in order to contextually choose questions, question selection 120 can retrieve data generated by activity monitoring devices 191 (762). This can include direct indicators of health such as heart rate, blood sugar, and cholesterol levels (763) as well as information regarding exercise such as steps taken per day, calories burned, and average activity levels (764). These devices typically include sensors such as accelerometers, a gyroscope, compass, GPS, and a light sensor, among others, that can be used to calculate certain health parameters like quality of sleep and distance traveled per day (765). In addition, GPS and clock data can be combined with other health and fitness data in order to determine a user's schedule and where the user is located (766).

After retrieving the activity monitoring device data, question selection 120 can choose questions taking into account the data (768). For example, if health data shows that a user has high blood pressure, questions relating to how to lower blood pressure can be chosen. If the user is shown to have poor sleep quality, questions about tips to get better sleep can be chosen. If the user has just finished a workout, questions about post-workout recovery can be chosen. If a user is determined to be a new runner, questions about basic running knowledge can be chosen, whereas if a user is an advanced runner, more advanced questions can be chosen instead.

Location data and time data can also be used to interpret a user's schedule and choose appropriate schedule-related questions. For example, if the data show that a user commutes via a long subway ride every weekday, questions about exercise ideas for long commuters can be shown. If a user is detected in a restaurant, questions regarding healthy food choices can be shown, and if a user is in a grocery store, questions about vegetables, organic food, and nutrition can be shown.

In order to encourage participation and development of accurate health outcome scores and determinations, a gaming environment can be established in which users are asked questions in a competitive or semi-competitive context (720). An example of a gaming environment is shown with environments depicted through interfaces of FIG. 8A through 8H.

Example Interfaces

FIG. 8A through 8H illustrate example interfaces for use with one or more embodiments described herein. Interfaces such as described with FIGS. 8A through 8H can be implemented using, for example, a system such as described with an example of FIG. 1 . Accordingly, reference may be made to elements of FIG. 1 for purpose of illustrating suitable components for implementing an interface as described.

In FIG. 8A, in interface 800 provides a topical selection 804 for a user (e.g., nutrition). The interface 800 can be displayed with information from the user's profile 138, such as their game score 802 (e.g., provided as game data 119 of the user's profile, in an example of FIG. 1 ) and badges or certifications 805.

The panel 810 of FIG. 8B illustrates a question 812, in the form of trivia. A set of answers 814 can be provided to the user, from which the user can make selection of in order to affect his or her score.

FIG. 8C illustrates a panel 820 that provides feedback 825 to the user as to the correctness of the answer, as well as supplemental information regarding the correct answer and/or assertion underlying the question. In FIG. 8D, once the user provides the answer, the user can be provided an additional panel 830, displaying the underlying assertion 832 behind the question. Other information, such as the percentage of individuals who answer the question correctly can be displayed to the user. This feature 834 can also reflect the difficulty level of the question.

FIG. 8E illustrates a panel 840 on which a menu of options is provided. The user can select from the menu of options. As shown, the functionality provided includes gaming (e.g., leader board) and community interaction (e.g., discussions), in a gaming and social environment such as described with an example of FIG. 1 . Additionally, the menu of options can include a health report feature 842 that can display, for example, recommendations as determined from an example of FIG. 7 .

FIG. 8F illustrates a panel 850 that provides a gaming summary for the user, displaying the user's overall score 852, as well as badges are honors marking 854 achievements in the number of questions the user answered etc.

FIG. 8G illustrates a panel 860 on which a leaderboard 862 is provided. The leaderboard can be topic specific and/or categorized by user level.

FIG. 8H illustrates the panel 870 for enabling social interaction, gaming and knowledge base forums through a system such as described with an example of FIG. 1 . Among other social interaction functions, one or more knowledge base “twins” can be identified to the user. The twins can correspond to an individual who closely shares one or more of (i) knowledge profile about health, or certain topics of health with the user, and/or (ii) similar or same health outcome values or determinations. As an addition or variation, the twin can also include similar demographic profile, such as having the same gender, age and/or race. Identify twins can be shown to each other as a mechanism for building social interaction and shared experiences, particularly as to distributing health-based knowledge, information and services.

Computer System

One or more embodiments described herein provide that methods, techniques and actions performed by a computing device are performed programmatically, or as a computer-implemented method. Programmatically means through the use of code, or computer-executable instructions. A programmatically performed step may or may not be automatic.

One or more embodiments described herein may be implemented using programmatic modules or components. A programmatic module or component may include a program, a subroutine, a portion of a program, or a software or a hardware component capable of performing one or more stated tasks or functions. As used herein, a module or component can exist on a hardware component independently of other modules or components. Alternatively, a module or component can be a shared element or process of other modules, programs or machines.

Furthermore, one or more embodiments described herein may be implemented through instructions that are executable by one or more processors. These instructions may be carried on a computer-readable medium. Machines shown or described with figures below provide examples of processing resources and computer-readable mediums on which instructions for implementing embodiments of the invention can be carried and/or executed. In particular, the numerous machines shown with embodiments of the invention include processor(s) and various forms of memory for holding data and instructions. Examples of computer-readable mediums include permanent memory storage devices, such as hard drives on personal computers or servers. Other examples of computer storage mediums include portable storage units, such as CD or DVD units, flash or solid state memory (such as carried on many cell phones and consumer electronic devices) and magnetic memory. Computers, terminals, network enabled devices (e.g., mobile devices such as cell phones) are all examples of machines and devices that utilize processors, memory, and instructions stored on computer-readable mediums. Additionally, embodiments may be implemented in the form of computer-programs, or a computer usable carrier medium capable of carrying such a program.

FIG. 9 is a block diagram that illustrates a computer system upon which embodiments described herein may be implemented. For example, in the context of FIG. 1 , FIG. 2 , FIG. 6B and FIG. 7B, a network service or system can be implemented using one or more computer systems such as described by FIG. 9 . Still further, methods such as described with FIG. 4 , FIG. 5 , FIG. 6A and FIG. 7A can be implemented using a computer system such as described with an example of FIG. 9 .

In an embodiment, computer system 900 includes processor 904, memory 906 (including non-transitory memory), storage device, and communication interface 918. Computer system 900 includes at least one processor 904 for processing information. Computer system 900 also includes a memory 906, such as a random access memory (RAM) or other dynamic storage device, for storing information and instructions to be executed by processor 904. The memory 906 also may be used for storing temporary variables or other intermediate information during execution of instructions to be executed by processor 904. Computer system 900 may also include a read only memory (ROM) or other static storage device for storing static information and instructions for processor 904. The communication interface 918 may enable the computer system 900 to communicate with one or more networks through use of the network link 920 (wireless or wireline).

In one implementation, memory 906 may store instructions for implementing functionality such as described with example systems or sub-systems of FIG. 1 , FIG. 2 , FIG. 6B or FIG. 7B, or implemented through example methods such as described with FIG. 4 , FIG. 5 , FIG. 6A or FIG. 7A. Likewise, the processor 904 may execute the instructions in providing functionality as described with example systems or sub-systems of FIG. 1 , FIG. 2 , FIG. 6B or FIG. 7B, or performing operations as described with example methods of FIG. 4 , FIG. 5 , FIG. 6A or FIG. 7A.

Embodiments described herein are related to the use of computer system 900 for implementing functionality as described herein. The memory 906, for example, can store a question library 931 (see, e.g., also question library 152 of FIG. 1 ), including values for health correlative parameters 933 (see e.g., also health correlative parameters 151 a of FIG. 1 ) of the some questions. The memory 906 can also store instructions 941 for determining a health score, in order to determine one or more correlative health parameters for a user, in connection with the user's participation of responding to questions in an interactive community or game environment. According to one embodiment, functionality such as described herein can be performed by computer system 900 in response to processor 904 executing one or more sequences of one or more instructions contained in the memory 906. Such instructions may be read into memory 906 from another machine-readable medium, such as through a non-transitory storage device. Execution of the sequences of instructions contained in memory 906 causes processor 904 to perform the process steps described herein. In alternative embodiments, hard-wired circuitry may be used in place of or in combination with software instructions to implement embodiments described herein. Thus, embodiments described are not limited to any specific combination of hardware circuitry and software.

Mortality System Overview

FIG. 10 illustrates a real-world mortality information system, according to an embodiment. In particular, FIG. 10 illustrates a real-world mortality information system 1000 for extracting real-world data about mortality outcomes for the purpose of determining whether knowledge of underlying assertions can be correlated to mortality rate. According to some embodiments, individual questions, or alternatively groups of questions, can be correlated to a quantifiable metric that statistically relates a user's knowledge (or lack of knowledge) for an underlying assertion to a likelihood of a mortality outcome. Some embodiments of the system 1000 can be implemented as a sub-system of a health/mortality predictive system 100, such as shown with an example of FIG. 1 . Determinations such as described with various examples may include determining health, mental health, mortality, morbidity, or underwriting class for health/life insurance.

In more detail, system 1000 includes one or more third party interfaces 1010 that can indicate whether an individual has passed away. The third party interfaces 1010, for example, can include interfaces to social media sites (e.g., FACEBOOK, TWITTER, LINKEDIN, INSTAGRAM, etc.) and/or obituary services, which can provide information about individuals of a user base, including whether users are deceased. Social media sites may, for example, carry content marking the death of a user. Such content may include photographs and/or text posted by friends and family. The social media accounts of users may be accessed by their content. As described with numerous examples, in subsequent months and years, the accounts of users with such sites may be accessed to determine (or verify determination made through a separate source) those users who have deceased. In some variations, the social media accounts of friends, family members, and/or employers for individual users may also be utilized to determine (or verify) when a user is deceased.

The system 1000 can include a content analysis system 1020 that includes functionality for receiving real-world user data 1011 from third party interfaces 1010. The third-party interfaces 1010 may include social media sites and/or obituaries services. The real-world user data 1011 can include social network content and/or obituary content.

In one implementation, the content analysis system 1020 utilizes analysis rules 1022 to generate a determination of a real-world mortality outcome (e.g., whether the user is deceased, living, and/or unknown) for an individual. The analysis rules 1022 can be implemented as a formula or model, and can image analysis 1030 and/or text analysis logic 1040.

In some embodiments, the image analysis 1030 and/or text analysis logic 1040 data can operate on respective image and text content to identify hints, clues or explicit evidence of a user's mortality outcome. For example, text analysis logic 1040 may parse text content from a social network account to identify tribute markers and/or keywords 1032. Likewise, image analysis 1030 can recognize text in images in order to identify tribute markers/keywords 1032. Thus, the tribute markers/keywords 1032 may be markers identified through image and/or word recognition. By way of example, tribute markers may include “we will miss you,” “rest in peace,” “our condolences,” “sorry for your loss,” “in a better place,” “everything happens for a reason,” “will be in our thoughts and prayers,” etc. Markers through image recognition can also be extracted from photographs, such as photographs of grave markers or tombstones.

In some variations, the social networking content of relatives, friends or employers may also be analyzed to confirm or weight a determination of mortality outcome. For example, links to the social networking page of a given user may be analyzed to determine an account of a spouse or close relative. The social networking account of the relative can then be analyzed for markers that indicate the loss of a loved one. The markers may be specific to the relationship between the relative and the person for whom the mortality determination is being made.

A sentiment analysis component 1034 can also analyze social network content associated with a user account to determine an overall sentiment 1035 for the social network content in a given time frame. The sentiment analysis component 1034 may utilize an output of image analysis 1030 and/or text analysis 1040 (e.g., tribute markers/keywords 1032). As an alternative or addition, the sentiment analysis component 1034 may process social network content directly from the user's account. An output of the sentiment analysis component 1034 may include a sentiment 1035. The sentiment 1035 may represent one of multiple possible sentiment values, such as (i) sad or not sad, (ii) sad, happy, neutral or (iii) sad, happy, angry, neutral.

Mortality determination logic 1046 may receive input from 1020, and determine a mortality output 1049. The mortality output 1049 can identify a user (e.g., by name, by moniker, hashed identifier, etc.) and associate the user with a mortality determination. The mortality determination can correspond to, for example, one of alive, deceased, unknown. In variations, the mortality determination can also be associated with a confidence score, which indicates a certainty of the determination. For example, if the confidence score is above a threshold, the mortality determination may indicate that the user is deceased. However, if the confidence score is below the threshold, the mortality determination may indicate that the user is likely deceased, or alternatively, unknown as to alive or deceased.

According to examples, the mortality determination logic 1046 employs programmatic methodologies in order to make the mortality determination for given individual automatically, and without input from a human. In some examples, system 1000 operates in an anonymized manner, so that input and output from system 1000 is not accessible to humans. For example, real-world user data 1011 may be encrypted, and the association between user and mortality determination may be in the form of a protected tuple a data set. The programmatic methodologies can include, for example neural network or random forest algorithms, which can associate weights and confidence values to markers/keywords 1032. In some examples, the mortality determination logic 1046 also obtains contextual data relating to markers/keywords 1032. The contextual data can for example, identify relative placement of keywords in a phrase (e.g., words towards the beginning of a sentence versus in the middle of a paragraph), placement of markers/tributes 1032 in captions of images, prominence of markers/tributes 1032 etc.

Additionally, in some examples, sentiment 1035 can be used to weight markers/keywords 1032 for or against a particular determination. For example, the marker/tribute 1032 for a particular user may include a keyword that is strongly associated with a mortality determination of deceased, but the particular marker may be devalued (e.g., associated with a low confidence score) because a sentiment 1035 of posts and comments related to the text indicate a relatively happy mood.

In some examples, when the mortality determination logic 1046 determines that an individual is deceased, the name of the deceased individual can be generated and sent to a name comparison component 1050, which compares the deceased's name to names within a user name database 1060. The user name database 1060 may, for example, include names of individuals within a user population, or alternatively, within a control population of the user base. The name of the deceased individual may be included as real-world information 1070 that is output once a match to a name in the user name database 1060 has been established. The real-world information 1070 can be compared to expected mortality outcomes in a physiological health, mental health, mortality, morbidity, and/or underwriting predictive system 100 (such as shown with an example of FIG. 1 ), where the comparison between actual mortality outcomes and expected mortality outcomes within the control group can be included in determining how knowledge of underlying assertions is correlated with mortality rate.

In some variations, the content analysis system 1020 may receive user names within the user name database 1060 and then analyze social network content from third party interfaces 1010 for social network accounts associated with those user names. For example, the content analysis system 1020 can receive a user name from the user name database 1060 through the name compare system 1050. The third party interfaces 1010 can be searched with each received user name to verify whether the individual associated with each user name is deceased. This can be done on a continuous basis.

According to some examples, when individuals in the user name database 1060 are determined to be deceased, they can be added to the control group for determining correlative mortality parameter values. In some examples, the individuals are added to the control group if certain conditions are satisfied, such as age (e.g., only individuals above 50 are added to the control group), cause of death (e.g., accidental or non-natural cause of death is not considered).

In some variations, one or more additional verification processes can be performed to verify an alternate determination that an individual of a control group (or candidate thereof) is deceased. For example, system 100 may identify past and current users who have deceased from a given source, such as third-party obituary services. In such examples, a separate verification process (or set of processes) can be implemented to verify a past or current user that is determined to be deceased through the alternate source. In some examples, a programmatic process may be implemented to confirm or otherwise verify that an individual is deceased.

In one implementation, the programmatic verification process may include analyzing content of the social networking page of the users who have been identified as deceased through an alternative or independent source. For such users, the verification process can include scanning content of social networking accounts of users who have been identified as deceased in order to confirm the user is deceased. As described with other examples, the analysis can include parsing text and analyzing images for markers that are typical for deceased persons.

In some variations, social networking accounts of family members for such users can be identified programmatically, through, for example, links provided on a user's social networking page. The accounts of the family members may also be analyzed to further verify the determination that the original user is deceased. For example, the social networking page of a spouse can be analyzed for markers that indicate a loss of the individual's spouse. The markers may be specific to the relationship between the family member and the original user who is thought to be deceased.

Lifestyle Categorization Determinations

FIG. 11 illustrates a system to categorize a lifestyle of a user, according to an embodiment. In some examples, a lifestyle determination system 1100 extracts and analyzes social media content about a user in order to determine one or more lifestyle categorizations of the user. The system 1100 may be implemented through one or more computers, such as described with, for example, FIG. 9 . For example, the system 1100 may be implemented through use of a server, or set of servers, which programmatically interface with social networking sites in order to determine lifestyle categorization, as described with examples provided below.

According to some embodiments, individual questions, or alternatively groups or series of questions, can be correlated to a quantifiable metric that statistically relates a user's knowledge (or alternatively lack of knowledge) of an underlying assertion to one or more characteristics of the user. The one or more characteristics of the user may be related to the user's physiological health, mental health, mortality rate, morbidity rate, and/or underwriting class can be associated with one or more related attributes that can be verified through social media content. Some embodiments of the lifestyle determination system 1100, for example, can be implemented as a sub-system of a system 100, such as shown in FIG. 1 .

In an example of FIG. 11 , the system 1100 may include a user categorization system 1102 and a social network content analysis (“SNCA”) component 1108. The SNCA component 1108 analyzes social network content of individual users to determine characteristics or traits of the user, from text and/or image content, as well as metadata and affiliations or social connections.

The SNCA component 1108 may utilize programmatic interfaces to social networking services, in order to retrieve content from a specific user's account. In more detail, SNCA component 1108 may include functionality (“social network connectors 1118”) for retrieving or otherwise obtaining social network content of a user from a particular source. The social network connectors 1118 can, for example, interface with specific user accounts on social media sites such as FACEBOOK, TWITTER, LINKEDIN, INSTAGRAM, etc., to retrieve text and images from the user's account. In some variations, the SNCA component 1108 may utilize social networks connectors 1118 to retrieve social network content from accounts which are linked to the user, for individuals whom are identified as the spouse, sibling, parent, child, close friend or co-worker.

In some implementations, the social network content of a user can be analyzed to determine a set of attributes 1106 from which a lifestyle categorization may be inferred. The SNCA component 1108 may include an image analysis component 1112, a text analysis component 1114, and an affiliation analysis component 116. The SNCA component 1108 may use the image analysis logic 1112 to perform image analysis of objects, text or persons, in order to determine markers of a particular lifestyle category. For example, the image analysis logic 1112 may be analyzed to determine whether the user participates in sporting events, attends barbecues, or is a smoker. The text analysis logic 1114 may parse captions, comments, or postings of the user to determine events or activities which the user participated in, as well as hobbies or interests of the user. In some implementations, the text analysis logic 1114 may access a list or library of keywords in order to determine whether the keywords exist in the social network content of a given user. As an addition or variation, the text analysis logic 1114 may identify contextual data about textual content, including placement of individual words relative to, for example, a beginning of an entry or to other words. Still further, in some variations, the text analysis logic 1114 may perform sentiment analysis on individual posts or entries to determine a user's sentiment about a particular event or caption.

The affiliation logic 1116 can identify social connections of the user, and process content or known information about the connections in order to determine interests, activities, events or other information about a user. The relevance of identified affiliations may be based on assumptions. In some examples, affiliations may be used as a form of verification. For example, an assumption may exist that vegans and smokers tend to have spouses who are also vegans or smokers. The SNCA component 1108 may thus identify such connections using the affiliation logic 1116, and then process the social network content of such connections using the image analysis logic 1112 and the text analysis logic 1114.

In some embodiments, the image analysis logic 1112, the text analysis logic 1114, and/or the affiliation logic 1116 data can be analyzed for respective attributes 1106 of a predefined lifestyle category. The attributes 1106 can be determined from social network content 1101 through image and textual analysis. Additionally and/or alternatively, content can be associated with connections of the user in a particular social network forum. As output, the SNCA component 1108 may determine one or multiple attributes 1106, each of which may relate to a lifestyle category.

In some variations, the user's commentary or activity can also be detected and analyzed. For example, the users “likes” or comments can be detected, and a subject of the activity may be extracted from the content and analyzed for text and image content.

The SNCA component 1108 may determine individual attributes 1106 along with a score which indicates a confidence that the attribute is that of the user. For example, the SNCA component 1108 may determine as an attribute, that the user is a turkey eater by analyzing Thanksgiving pictures from the user's social network account. The determination that the user is a turkey eater can be relevant to whether the user is a vegan. The attribute 1106 for Thanksgiving turkey eater can be provided a score that measures a confidence related to one or more of the following: (i) the content analyzed in fact showed a turkey as part of a Thanksgiving feast (e.g., image of cooked turkey), (ii) the user participated in that particular Thanksgiving feast (e.g., “lovely dinner at our in-laws”), and/or (iii) the user ate turkey on that event (e.g., text content “Turkey was delicious!”).

As another example, the SNCA component 1108 may identify attributes 1106 which have strong associations with a particular lifestyle category. For example, the affiliation logic 1116 may identify the presence of a link to a cigar club, which would provide strong indication that the person smokes cigars. At least one of the attributes 1106 which is output by the SNCA component 1108 may identify as cigar smoker.

Similarly, the image analysis logic 1112 may be trained to detect cigarettes (e.g., orange tips and smoke) in the user's images, and then perform image recognition to identify the user's face in relation to the cigarette. In such an example, the SNCA component 1108 may output an attribute 1106 of cigarette smoker. A confidence score may reflect a certainty to which a cigarette was detected in the social content of the user, as well as a certainty that the user was the one smoking the cigarette.

As another example, the SNCA component 1108 may be triggered to retrieve content from a spouse of a user in order to determine second order attributes 1107, which may be probative of a particular lifestyle categorization. For example, an assumption may be implemented by the user categorization system 1102, such as an assumption that vegans have spouses that are also vegans. Still further, the SNCA component 1108 may analyze affiliations to identify groups or organizations which the user may support. For example, the user categorization system 1102 may also implement the assumption that an SPCA supporter is more likely to be a vegan.

In some embodiments, the attributes 1106 which are determined for the user can include both positive and negative attributes, where positive attributes correlate positively with the categorization and negative attributes inversely correlate with the categorization. For example, if the user is categorized as “vegan,” an affinity for barbecue (e.g., the user hosts a barbecue, as determined from text and image content) would be a negative attribute that would cause the system 1100 to determine the categorization may not be accurate for the user.

Still further, the social network content 1101 of users can be analyzed for markers and/or keywords that correlate to attributes 1106. Additionally, connections and affiliations, such as of related persons (e.g., spouse, sibling, child, parent, close friend, employer, supported organization) can be identified for relevance. In some examples, social network content from such connections may be retrieved and analyzed for probative attributes 1106. For example, a user categorized as “vegan” may have a spouse identified through FACEBOOK. In that case, the system 1100 can search for the spouse's name and, if there is a match, better correlate the user with the “vegan” category (e.g., by weighting the category more heavily).

The user categorization system 1102 may implement one or more rules or models (e.g., neural network, random forest) to determine one or more lifestyle categories for a user, based at least in part on the attributes 1106 determined from processing the user's social networking content. By way of example, the lifestyle categories can include (i) whether the user is a vegetarian, (ii) whether the user is a smoker, (ii) whether the user is a cigar smoker, (iv) whether the user sits a lot during the workday (e.g., based on images from work), (v) whether the user participates in athletic events, (vi) whether the user prepares his own food or eats out. In variations, more refined categorizations may be utilized, such as dietary habits (e.g., Mediterranean, vegan, vegetarian, pescatarian, raw food, paleo, etc.), exercise habits (e.g., athlete), and/or demographic information (e.g., wealth, class status, education level, age, gender, geographic location, families and living arrangements, etc). Each lifestyle category 1111 can include a category definition.

In some examples, the category definitions may include a set of attributes which individually carry a different weight relative to other attributes in regards to determining whether a particular lifestyle category is applicable to a user based on their social network content. According to some examples, the category definitions for individual categories include (i) one or more attributes which necessarily indicate the user has a particular lifestyle category (e.g., content showing the user eating meat means he is not a vegan, and non-vegan lifestyle category), (ii) one or more attributes which strongly indicate the user is of a particular lifestyle category (e.g., a single picture of the user near a cigarette is a strong indicator, but not conclusive that the user is a smoker), and/or (iii) one or more attributes which moderately indicative of a lifestyle category (e.g., a user posting about runs is moderately indicative of an athletic lifestyle). The user categorization system 1102 may implement a model or scoring algorithm to determine, from attributes 1106, which of multiple possible lifestyle categories the user belongs in.

As an addition or variation, the user categorization system 1102 may determine one or more user parameters that correlate to the determined lifestyle categorization 1124. In some examples, the user categorization system 1102 can associate a user categorization score associated with the lifestyle categorizations 1124 of the user. The user categorization score may be a percentage or weight correlated with the likelihood of the user falling within the categorization. In variations, the user categorization score may reflect a magnitude by which a person can be viewed as having a particular lifestyle (e.g., light smoker versus heavy smoker; pure vegan or vegan with exceptions, etc.).

In some implementations, the lifestyle categorizations 1124 can be used to configure implementation and/or use of system 100 for a given user. For example, the lifestyle categorizations 1124 can be stored with a user profile, and the lifestyle categorizations 1124 can be used to determine which questions to ask the user. Alternatively, the lifestyle categorizations 1124 can be used to weight the health outcome score 165 a and/or mortality outcome parameter 165 b determined from the system 100.

As an addition or variation, the lifestyle categorizations 1124 can be utilized as input in determining, for example, a person's eligibility or pricing for a product or service that can be valued on, for example, the user's well-being and/or longevity. By way of example, the lifestyle categorizations 1124 can be used to reduce the premium or deductible a person pays for health or life insurance. Still further, the lifestyle categorizations 1124 may be used to determine an individual's eligibility for a product or service.

In some variations, the lifestyle categorizations 1124 is used in combination with one or more other inputs in order to determine eligibility or pricing for products or services such as health and life insurance. For example, the lifestyle categorizations 1124 may be used in combination with outputs of system 100 in order to determine pricing and/or eligibility for insurance products.

In some examples, the lifestyle categorizations 1124 can be predictive without input from the user. The categorizations 1124 can be associated with characteristics of the user that can be quantifiable such that the characteristics (and, accordingly, categorizations) can be verifiable from independent sources, such as subsequent input from the user or from determinations of system 100 (e.g., after user answers sufficient questions to develop profile). In some examples, the lifestyle categorizations 1124 can be verified by independent sources, and then used to train one or more models of the user categorization system 1102.

In some embodiments, the lifestyle categorizations 1124 can be used to verify or refine categorizations of a user based on the user's knowledge of assertions, as determined from answering questions selected from the system 100. For example, the system 100 can generate fact-based questions on various topics of health for the purposes of (i) obtaining responses from users, and (ii) correlating all or some of those responses to physiological health, mental health, morbidity rate, mortality rate and/or underwriting class (for health or life insurance) predictions. Accordingly, a user may make an assertion related to (e.g., answer) one or more fact based questions, and from the user's assertions, the user's independent knowledge of the assertion can be determined. From this, the user categorization system 1102 can make predictions about the user's attributes and, accordingly, categorize the user on that basis. In some embodiments, correlating responses to category predictions may be done through a correlative model or formula that is developed using a control population, such that the user's independent knowledge can be compared to the control population's independent knowledge.

FIG. 12 illustrates an automated method for utilizing information about a user. A method such as described with an example of FIG. 12 may be implemented using, for example, a system such as described with an example of FIG. 1 or FIG. 11 . Accordingly, reference may be made to elements of other examples for purpose of illustrating a suitable component for performing a step or sub-step being described.

With reference to FIG. 12 , the system 1100 may obtain social network content for one or more users of a user base (1210). The user base may correspond to, for example, users of system 100, who may answer questions and have their knowledge evaluated to correlate their knowledge with health and mortality outcomes. Accordingly, the social network content may be determined using, for example, social network connectors 1118, which automatically retrieve content for individual users, or for a group of users in bulk.

SNCA component 1108 may analyze the social network content to determine one or more attributes for each user (1220). The text analysis logic 1114 of the SNCA component 1108 can include text analysis, which analyzes keywords, placement of keywords, and contextual data of key words and other text on a user's social networking page (1222). The key words can be filtered or correlated to a set of attributes, which are predetermined to a definition of a lifestyle category.

As an addition or alternative, the SNCA component 1108 may include the image analysis logic 1112, which can execute to recognize predetermined objects which are deemed markers of a particular lifestyle category (1224). For example, the system 1100 may use the image analysis logic 1112 to recognize the tips of lit cigarettes, in order to determine an attribute for the lifestyle category of a smoker. Similarly, the system 1100 may use the image analysis logic 1112 to recognize cooked meat, such as a turkey or burger, in order to determine an attribute for non-vegan.

Still further, the affiliation logic 1116 may identify affiliations, such as in the form of social connections with other users or associations (1226). Some affiliations to associations, for example, may be identified as an attribute which are relevant to a particular lifestyle (e.g., SPCA, for vegan). The affiliation logic 1116 may also identify social network content of other users to obtain and analyze.

In determining the attributes, the system 1100 may also determine an associated confidence score, which can relate to the confidence of the determination (1228). As an addition or alternative, the confidence score can measure the likely link between the user and the determined attribute. For example, a weak link (e.g., picture of turkey without the user at the table) may be indicated by a lower score than a strong link (e.g., user at table with turkey)

According to some examples, the system 1100 may determine a lifestyle category for the user based at least in part on the determined attributes (1230). The system 1100 may employ, for example, the user categorization system 1102, which can implement one or more models, rules or other logic to predict the lifestyle category for the user. The predicted lifestyle category may be associated with a confidence score, indicating the certainty of the determination.

FIG. 13 illustrates a health determination system for determining health-based products and services, according to one or more embodiments. According to some examples, a health determination system 1300 includes one or more health determination components which individually or collectively predict a health-related aspect of the user. The health-related aspect may correspond to, for example, a characterization (e.g., quantitative or qualitative) of the user's overall health. As an addition or variation, the determined health-related aspect may be predictive of a relative health of the user, based on a demographic parameter such as age and race of the user. Still further, the determined health-related aspect may be predictive of longevity, mortality or morbidity.

According to one implementation, a knowledge determination component 1310 provides an output that correlates a user's knowledge of health-related assertions to a health or mortality outcome. In some examples, the knowledge determination component 1310 may be implemented using a system such as described with FIG. 1 , and an output of the knowledge determination component 1310 may correspond to a knowledge correlative determination 1336. The knowledge correlative determination 1336 may represent a value that correlates a knowledge of the user about a health topic to a predictive health outcome. In particular, the knowledge correlative determination 1336 may correspond to a score or parametric value that for example, is predictive of one or more of a health outcome of the user, a health state of the user, and/or a mortality of the user. The knowledge correlative determination 1336 may be provided as input to the user health services 1340, to select one or more health products or services.

A lifestyle categorization component 1320 may be implemented to programmatically determine a lifestyle category of a user (shown as “lifestyle determination 1334”). According to some examples, the lifestyle categorization component 1320 may receive social network content 1312 from one or more social network sites 1308. As described with an example of FIG. 11 , the lifestyle categorization component 1320 may analyze text and image content, as well as affiliations of a given user's social network content, in order to make one or more lifestyle determinations 1334. The lifestyle determinations 1334 may identify categories, such as a dietary lifestyle (e.g., vegan) or a smoker lifestyle. Examples of specific lifestyle determinations 1334 include a classification of weightlifter, endurance athlete, a dieter, a person who practices preventative care, a triathlete or a person who has a low glycemic diet.

As described with other examples, the lifestyle determinations may be determined as confidence scores, using, for example, random forest or neural network algorithms. The algorithms may be trained off of users self reported habits, and compared to results determined from analyzing posts of individual users.

A user health model 1330 may predict a health profile of a user based on input that includes one or more of (i) knowledge correlation determination 1336 of the knowledge determination component 1310, and/or (ii) lifestyle determinations 1334 as determined from the lifestyle categorization component 1320. As an addition or alternative, the health determination system 1300 may utilize user biological input 1302, which can include information such as hip-to-waist ratio, triglyceride levels of the user, the user weight, body mass index (“BMI”) or other information. As another addition or variation, the user health model 1330 may use social network content 1312 as input. The user health model 1330 may implement any one or more algorithms, to determine health profiles 1332 for individual users. In some examples, the health profiles 1332 may include classifications of the user's overall health or mortality. The classifications may be quantitative. Additionally, the classifications may be provided with a confidence score, indicating, for example, a probability that the classification for the user is accurate.

The user health services 1340 may include functionality to select a health service or product for the user. The health service or product may be of a type in which a price or other material aspect is dependent on a health of the user. The user health services 1340 may use inputs, corresponding to, for example, one or more of the health profile 1332, lifestyle determinations 1334, and/or the knowledge correlative determinations 1336. The user health services 1340 may include functionality 1342 to select a health service or product for the user. The health service or product may be of a type in which a price or other material aspect is dependent on a health of the user. Based on one or more of the inputs, the user health services 1340 may determine if a user may qualify for a health product or service, which includes various forms of life and health insurance. As an alternative or variation, the user health services 1340 may include functionality 1344 for determine a pricing for the product or service. The pricing may correspond to, for example, a price for a premium or deductible (e.g., or discount for same).

According to some examples, the user health services 1340 may determine a premium or deductible for a health or life insurance based on a predicted life expectancy of the user. In variations, the user health services 1340 may determine the premium or life expectancy based on information about the user and a class or sub-class of the user. The information about the user may be determined by one or more of (i) a knowledge correlative determination 1336 of the user, (ii) the biological input 1302 provided by the user. Thus, the user health services 1340 may utilize both personal information and information about a class or sub-class of the user.

Health Validation and Prediction System

FIG. 14 is a block diagram illustrating an example computing system 1400 implementing remote health-assertion verification and health prediction using big data techniques, according to examples described herein. The computing system 1400 described in connection with FIG. 14 may be implemented on one or more servers including one or more processors executing software developed for performing the techniques described herein, such as a datacenter with network connectivity to the computing devices of users 1497. The computing system 1400 can include a network interface 1425 to communicate with the computing devices 1495 of users 1497 over one or more networks 1480. For example, a user 1497 can launch a health service application 1496 on the user's computing device 1495, which can generate an interactive user interface in which the user 1497 can select from any number of health-related topics in order to initiate a trivia session. In some examples, the user 1497 can initially provide certain personal information, such as height, weight, age, sex or gender, ethnic background, and the like. In further examples, the health application 1496 can query the user for additional information, such as whether the user 1497 self-identifies as one or more activity-based or health-based classifications. As described herein, these activity-based or health-based classifications can correspond to athletic activities (e.g., running, swimming, hiking, cycling, walking, sports, etc.), exercise routines (e.g., an amount of time spent doing specified activities or at the gym), nutritional or dietary habits, any substance usage habits (e.g., smoking), and the like.

According to examples described herein, once the user 1497 makes these self-classification selections, the user 1497 can initiate a health trivia session by selecting a trivia session feature on the interactive user interface displayed through the health service application 1496 on the computing device 1495 of the user 1497. The trivia engine 1450 of the computing system 1400 can initiate and manage the trivia session in combination with a selection engine 1430 which can utilize user profile 1471 data of the user 1497 in a service database 1470 to select health assertions 1478 from an assertion library 1471 to which the user 1497 can respond.

As described herein, each health assertion 1478 in the library 1476 can be associated with a topic, and organized within a topic list 1477. The topic list 1477 can include any particular topic related to health, and can correspond to a health trivia session. For example, the user 1497 can select a topic from the topic list 1477, which will include assertions 1478 from that selected topic for the trivia session. The selection engine 1430 can select all the assertions 1478 under a selected topic at once for the trivia session, or can select individual assertions 1478 based on the responses provided by the user 1497. For example, if the user 1497 answers correctly, the selection engine 1430 can select progressively more difficulty assertions 1478.

According to examples described herein, the service database 1470 can store a user profile 1471 for each user 1497, which can indicate the user's personal information, a mortality table applied to the user 1497, one or more morbidity tables (e.g., past tables as well as current tables), and any health service products the user 1497 utilizes or has purchased (e.g., life insurance or health insurance). The service database 1470 can further include the assertion library 1476, which can store health assertions or questions 1478 based on the topic list 177, and determine a correlation value 1479 for each health assertion 1478 based on actual health outcomes from control group users.

It is contemplated that the users 1497 can include control group users, or can become control group users once actual health outcomes are known for those users 1497 (e.g., the death of the user). The service database 1470 can adjust the correlation values 1479 of health assertions as new health outcome data is determined or received from the users 1497. When new health outcome data is received from users (e.g., new control group users), the computing system 1400 can determine the specifics of the health outcome(s) and perform lookups in the user profiles 1471 of these new control group users. The user profiles 1471 can include data from previous health trivia sessions, assertions or questions answered, the responses provided by the users, whether those responses were correct or incorrect, and the like.

Using the profile data and the nature of the actual health outcomes of these new control group users, the computing system 1400 can make adjustments to the correlation values 1479 of the questions or assertions answered by the new control group users. As provided herein, the health outcome(s) can comprise any morbidity or mortality outcome, including a disease diagnosis, health screening results, a heart attack, an illness, an increased risk of death, an actual death, and the like. As further provided herein, the computing system 1400 can determine actual health outcomes through any number of methods, including analyses of obituaries, social security death index, public or permission-accessed medical data, public or permission-accessed social media content, and the like. The changes reflected in the correlation values 1479 can indicate a greater or lesser correlation between the health assertions 1478 and the actual health outcome(s) experienced by the control group users, based on the questions or assertions 1478 answered, and whether they were answered correctly or incorrectly.

During a given trivia session, the trivia engine 1450 can generate content on the interactive user interface displayed on the computing device 1495 of the user 1497, presenting topical questions or health assertions 1478, prompting the user 1497 for a selected response (e.g., from a multiple choice list of possible responses), indications of whether the user 1497 provided a correct or incorrect response, and the like. The trivia engine 1450 can further present recommendations and/or explanations to provide added context to the reason why a particular response is correct or incorrect.

In various implementations, the computing system 1400 can include a scoring engine 1440 that can score the results of the health trivia session against other users 1497, generate a health knowledge profile for the user 1497 based on the health trivia session, the selected topic, and the user's responses. The scoring engine 1440 can further output an overall score, or a topical score for the user 1497, indicating a variety of scores or percentile rankings of the user 1497 based on health-related topics. The computing system 1400 can further include a user interface content generator 1460 which can present a final health knowledge user interface element via the interactive user interface. In certain examples, the final user interface element is displayed at the conclusion of a health trivia session, and can provide the user 1497 with a ranking or performance level as compared to other users 1497 (e.g., a percentile ranking of health knowledge).

In certain implementations, the content generator 1460 can present additional content, such as an overall health report based on the health knowledge of the user 1497 in specified topics, the user's profile data (e.g., age, height weight, BMI, known medical information, sex or gender), and any known health outcomes of the user 1497. In certain examples, the content generator 1460 can further present a progress chart indicating the user's strengths and weaknesses in terms of health progression and/or health knowledge progression. Since the health assertions 1478 are selected and filtered based on their high correlations to actual health outcomes, the progression of the user's health knowledge can also be correlated to actual health progression.

The content generator 1460 can further generate a leaderboard of the entire user base (e.g., either in total, or based on topic) and the user's ranking in comparison to the other users 1497. In certain aspects, the user interface element can be individually customized, providing the user 1497 with additional badges or awards (e.g., for being in the 90th percentile), qualifications for unlocking additional health quizzes, discounts offer for a health service product, and the like.

In various implementations, the computing system 100 can include a verification engine 1420 which can verify, based on the results of the health trivia session, the self-assertions or self-classifications regarding the user's own health. For example, knowledge of certain health assertions 1478 can also indicate whether a user's own assertions with regard to the user's health are verifiable. The verification engine 1420 can process the results of the health trivia quiz and generate a verification probability for each self-classification, where the verification probability comprises a probability that the user 1497 was accurate. It is contemplated that big data analytics can reveal patterns in user responses to the health assertions 1478 in a trivia sessions that can be utilized by the verification engine 1420 to verify the self-assertions of the user 1497 (e.g., whether a user's assertion of being a non-smoker is likely to be accurate).

For example, a user 1497 may self-classify as a non-smoker, or may self-identify as a triathlete or weight-lifter. The selection engine 1430 can select certain individual assertions for the purpose of verifying the user's self-health assertions as well as gauging the user's health knowledge. In one example, the verification engine 1420 can calculate and generate a verification probability with a given error range for each self-health assertion made by the user 1497. In one example, the user 1497 may have indicated a running hobby and participation in three to five marathons within the last two years. Based on this indication, the selection engine 1430 can select specific assertions 1478 to verify this claim, such as “what is the best method of treating shin splints?”—a question to which most marathoners would know the answer.

In various examples, the verification probability of a particular self-assertion of the user 1497 is below a certain threshold (e.g., when factoring in the error range), the verification engine 1420 can disregard or reverse the self-health claim or assertion made by the user 1497. Thus, the verification engine 1420 can output a more accurate health profile of the user 1497 to a health prediction engine 1410 of the computing system 100. This verified profile can eliminate any false or unverifiable self-health assertions made by the user 1497 and incorporate the health knowledge profile of the user 1497, and the personal information of the user 1497 (e.g., health screening information, age, height, weight, known medical information, etc.).

In some aspects, the verified profile can then be processed by the health prediction engine 1410 to generate a mortality table indicating a probability of death of the user 1497 over a given time frame (e.g., over the next five years). Additionally or alternatively, the health prediction engine 1410 can process the verified profile to determine a position of the user 1497 on a mortality table. As described herein, the mortality table can be custom-generated by the computing system 100 based at least in part on control group data of health knowledge profiles and actual health outcomes (e.g., mortality outcomes) of control group users, and can indicate the user's life expectancy—or probability of death over a given timeframe—given current health data and health knowledge profile of the user 1497. In further implementations, the prediction engine 1410 can generate a morbidity table for the user 1497. The morbidity table can indicate any health risks of the user 1497 and the seriousness of each health risk (e.g., a risk probability for each health risk). In some examples, the mortality and/or morbidity table can be provided to the user 1497 (e.g., via the customized user interface element generated by the content generator 1460). In variations, the table(s) may be hidden from user view, and utilized by one or more health service providers 1499.

In the latter case, the health service providers 1499 can include hospitals, urgent care units, medical facilities or offices, retirement communities, and the like. Such service providers 1499 can be provided with the table(s) through access via a health service interface 1470, and can utilize the table(s) to provide targeted health care for the user 1497 (e.g., addressing or treating the most pressing health risks first). In certain examples, the table(s) may be utilized for insurance underwriting, placing the user 1497 into specific underwriting classes for insurance pricing. For example, a healthy user 1497 with extremely low risk mortality probability and non-existent health risks as indicated in the morbidity table, can be provided with large discounts for health service products, such as insurance.

Methodology

FIGS. 15 and 16 are flow charts describing methods of remotely verifying self-assertions and predicting mortality and/or morbidity of a user, according to examples described herein. In the below description of FIGS. 15 and 16 , reference may be made to reference characters representing like features as shown and described with respect to FIG. 14 . Furthermore, the processes described with respect to FIGS. 15 and 16 may be performed by an example computing system 1400 as described with respect to FIG. 14 . Referring to FIG. 15 , the computing system 1400 can generate an interactive user interface for display on the computing devices 1495 of users 1497 (1500). The interactive user interface can present a health trivia game (1502) in which the user 1497 provides responses to a sequence of selected health trivia assertions (1504).

In various examples, the computing system 1400 can receive a corresponding sequence of responses to the health trivia assertions over the course of the health trivia session from the computing device 1495 of the user 1497 (1505). Based on the responses, the computing system 1400 can generate an individualized user interface element for the user 1497 (1510). This user interface element can provide the user with a health knowledge score (1512) and/or user classification or ranking as compared to other users 1497 (1514).

Further, based at least in part on the health knowledge of the user 1497, the computing system 140 can predict or otherwise determine any health risks or health outcomes for the user 1497 (1515). In certain implementations, the computing system 1400 can generate a mortality table based on control group health data and the health knowledge profiles of the control group. The computing system 1400 can determine the user's position in this customized mortality table (1517). As described herein, the mortality table can indicate the life expectancy of the user 1497 or a probability that the user 1497 will die within a given timeframe. In further examples, the computing system 1400 can generate a morbidity table for the user (1519). As further described herein, the morbidity table can comprise a set of health risks of the user 1497 (e.g., a probability for each potential diagnosis in a set of potential diseases or illnesses). As provided herein, the mortality table and/or morbidity table can be utilized for targeted health care and/or for pricing insurance products. It is contemplated that the use of big data techniques can result in accelerated insurance underwriting, in which no contact or health screening is required, and pricing can be performed remotely through the use of self-classification, verification using the health trivia techniques described herein, and the determination of the user's health knowledge.

Referring to FIG. 16 , the computing system 1400 can receive data indicating the start of a trivia session from a computing device 1495 of a user 1497 (1600). In some examples, the computing system 1400 can identify that the user 1497 has not provided self-health classifications. In such examples, the computing system 1400 can prompt the user 1497 to select a set of self-health classifications (1605). These classifications can comprise the user's own identification of self-health assertions (e.g., whether the user 1497 identifies as an athlete, any sports in which the user 1497 participates, duration of activities, healthy hobbies, and the like) (1607). In certain implementations, the self-health classifications can further indicate the user's own assessment of the user's dietary and/or activity habits (1609).

Based at least in part on the user's self-classifications, the computing system 1400 can select targeted questions or assertions 1478 for the health trivia session (1610). In certain examples, the questions or assertions 1478 may be selected with to goal of verifying the self-health assertions made by the user 1497 (1612). Additionally or alternatively, the questions or assertions 1478 may be selected to determine the health knowledge of the user 1497 (1614). The health trivia session may then be initiated by the user 1497. During the health trivia session, the computing system 1400 can receive a sequence of responses corresponding to the sequence of assertions 1478 from the computing device 1495 of the user 1497 (1615). At the conclusion of the health trivia session, the computing system 1400 can generate a customized user interface element that provides the health knowledge profile of the user 1497 on the display screen of the user's computing device 1495, as described herein (1620).

Based on the responses provided by the user 1497, the computing system 1400 can verify each of the user's self-health assertions (1625). For example, for each self-health assertion, the computing system 1400 can determine whether a verification probability threshold has been met or exceeded (1630). If so (1632), then the computing system 1400 can verify the self-assertion and proceed to scrutinize a next self-assertion (1640). However, in certain implementations, if the probability threshold is not met (1634), then the computing system 140 can disqualify or invalidate the self-assertion, and then proceed to scrutinize a next self-assertion (1640). Once all the self-assertions are scrutinized, the computing system 1400 can generate a predictive health profile for the user 1497 based at least in part on the health knowledge and verified assertions (1645).

For example, the computing system 1400 can determine the user's position in a mortality table generated based on control group data, which can indicate a probability that the user 1497 with die within a given timeframe (1647). Additionally or alternatively, the computing system 1400 can generate a morbidity table for the user 1497, indicating a set of health risks and/or the level of risk for the user 1497 for a set of diseases and/or illnesses. In various examples, the computing system 1400 can provide individually tailored health service products or benefits for the user 1497 (1650). Specifically, the health service products can comprise individualized pricing based at least in part on the health knowledge of the user 1497 (1654). Additionally or alternatively, the health service products (e.g., health insurance or life insurance) can be price or otherwise provided to the user 1497 based on the generated table(s) (1652). According to examples described herein, the computing system 1400 can receive health outcome data from the user base (1655). For example, the health outcome data may be determined from medical data, social media data, death index data, and the like. As describe herein, the computing system 1400 can update the control group and correlative health values for the health assertions 1478 in the assertion library (1476). Over time, the assertion library 1476 can filtered to include only highly correlative health assertions 1478 that are highly predictive of actual health outcomes.

It is contemplated for examples described herein to extend to individual elements and concepts described herein, independently of other concepts, ideas or systems, as well as for examples to include combinations of elements recited anywhere in this application. Although examples are described in detail herein with reference to the accompanying drawings, it is to be understood that the concepts are not limited to those precise examples. As such, many modifications and variations will be apparent to practitioners skilled in this art. Accordingly, it is intended that the scope of the concepts be defined by the following claims and their equivalents. Furthermore, it is contemplated that a particular feature described either individually or as part of an example can be combined with other individually described features, or parts of other examples, even if the other features and examples make no mentioned of the particular feature. Thus, the absence of describing combinations should not preclude claiming rights to such combinations. 

What is claimed is:
 1. A computing system implementing a health prediction service, comprising: a network communication interface to communicate, over one or more networks, with computing devices of users of the health prediction service; a database storing a library of health assertions, each health assertion in the library being associated with a correlation value based on responses to the health assertion from individuals in a control group of which a health outcome is known, wherein the health assertions are configured to test general health knowledge and not query user-specific information from the users of the health prediction service; one or more processors; and a memory resource storing instructions that, when executed by the one or more processors, cause the computing system to: based at least in part on (i) the responses to each health assertion provided by the individuals of the control group and (ii) health data of the individuals in the control group, generate a customized mortality table for the health prediction service, the customized mortality table being predictive of at least one of (i) an individual's probability of death over a given timeframe, or (ii) a life expectancy of an individual at a given age; generate, over the one or more networks, an interactive user interface for display on a computing device of a user of the health prediction service, the interactive user interface presenting a sequence of health assertions from the library of health assertions, wherein for each health assertion in the sequence, the user is prompted to select from a plurality of possible responses, and wherein a particular response from the plurality of possible responses to each health assertion in the sequence comprises a correct response; receive, over the one or more networks, a corresponding sequence of responses to the sequence of health assertions from the computing device of the user, each response in the corresponding sequence comprising either the correct response or an incorrect response; based at least in part on the corresponding sequence of responses, determine a mortality classification for the user using the customized mortality table of the health prediction service; and generate, via the interactive user interface, a service customer interface displaying a health service product for the user, the service customer interface enabling the user to redeem the health service product at a specified price that is based at least in part on the mortality classification of the user.
 2. The computing system of claim 1, wherein the executed instructions further cause the computing system to: receive, over the one or more networks, selection data indicating a set of self-classifications made by the user from the computing device of the user.
 3. The computing system of claim 2, wherein the set of self-classifications identify one or more health classifications of the user.
 4. The computing system of claim 2, wherein the executed instructions further cause the computing system to: based on the corresponding sequence of responses, verify the set of self-classifications made by the user.
 5. The computing system of claim 4, wherein the executed instructions cause the computing system to further determine the mortality classification of the user based on verifying the set of self-classifications.
 6. The computing system of claim 1, wherein the executed instructions cause the computing system to further determine the mortality classification of the user by determining one or more health risks of the user.
 7. The computing system of claim 1, wherein the mortality classification is utilized by the computing system to automatically generate a price structure for the health service product for the user.
 8. The computing system of claim 7, wherein the health service product comprises one of a health insurance product or a life insurance product.
 9. The computing system of claim 1, wherein the executed instructions further cause the computing system to: receive health update data indicating actual health outcomes of a subset of the users of the health prediction service; based on the health update data, incorporate the subset of users into the control group, and (ii) update the correlation value of one or more health assertions in the library of health assertions based on responses to the one or more health assertions provided by the subset of users.
 10. The computing system of claim 9, wherein the executed instructions further cause the computing system to: update the customized mortality table based at least in part on the updated correlation value of the one or more health assertions in the library of health assertions.
 11. The computing system of claim 9, wherein the correlation value correlates knowledge of each respective health assertion in the library of health assertions to a health outcome prediction.
 12. A non-transitory computer-readable medium storing instructions that, when executed by one or more processors of a computing system, cause the computing system to: communicate, over one or more networks, with computing devices of users of a health prediction service; store a library of health assertions in a database, each health assertion in the library being associated with a correlation value based on responses to the health assertion from individuals in a control group of which a health outcome is known, wherein the health assertions are configured to test general health knowledge and not query user-specific information from the users of the health prediction service; based at least in part on (i) the responses to each health assertion provided by the individuals of the control group and (ii) health data of the individuals in the control group, generate a customized mortality table for the health prediction service, the customized mortality table being predictive of at least one of (i) an individual's probability of death over a given timeframe, or (ii) a life expectancy of an individual at a given age; generate, over the one or more networks, an interactive user interface for display on a computing device of a user of the health prediction service, the interactive user interface presenting a sequence of health assertions from the library of health assertions, wherein for each health assertion in the sequence, the user is prompted to select from a plurality of possible responses, and wherein a particular response from the plurality of possible responses to each health assertion in the sequence comprises a correct response; receive, over the one or more networks, a corresponding sequence of responses to the sequence of health assertions from the computing device of the user, each response in the corresponding sequence comprising either the correct response or an incorrect response; based at least in part on the corresponding sequence of responses, determine a mortality classification for the user using the customized mortality table of the health prediction service; and generate, via the interactive user interface, a service customer interface displaying a health service product for the user, the service customer interface enabling the user to redeem the health service product at a specified price that is based at least in part on the mortality classification of the user.
 13. The non-transitory computer-readable medium of claim 12, wherein the executed instructions further cause the computing system to: receive, over the one or more networks, selection data indicating a set of self-classifications made by the user from the computing device of the user.
 14. The non-transitory computer-readable medium of claim 13, wherein the set of self-classifications identify one or more health classifications of the user.
 15. The non-transitory computer-readable medium of claim 13, wherein the executed instructions further cause the computing system to: based on the corresponding sequence of responses, verify the set of self-classifications made by the user.
 16. The non-transitory computer-readable medium of claim 15, wherein the executed instructions cause the computing system to further determine the mortality classification of the user based on verifying the set of self-classifications.
 17. The non-transitory computer-readable medium of claim 12, wherein the executed instructions cause the computing system to further determine the mortality classification of the user by determining one or more health risks of the user.
 18. The non-transitory computer-readable medium of claim 12, wherein the mortality classification is utilized by the computing system to automatically generate a price structure for the health service product for the user.
 19. The non-transitory computer-readable medium of claim 18, wherein the health service product comprises one of a health insurance product or a life insurance product.
 20. A computer-implemented method of implementing a health prediction service, the method being performed by one or more processors and comprising: communicating, over one or more networks, with computing devices of users of a health prediction service; storing a library of health assertions in a database, each health assertion in the library being associated with a correlation value based on responses to the health assertion from individuals in a control group of which a health outcome is known, wherein the health assertions are configured to test general health knowledge and not query user-specific information from the users of the health prediction service; based at least in part on (i) the responses to each health assertion provided by the individuals of the control group and (ii) health data of the individuals in the control group, generating a customized mortality table for the health prediction service, the customized mortality table being predictive of at least one of (i) an individual's probability of death over a given timeframe, or (ii) a life expectancy of an individual at a given age; generating, over the one or more networks, an interactive user interface for display on a computing device of a user of the health prediction service, the interactive user interface presenting a sequence of health assertions from the library of health assertions, wherein for each health assertion in the sequence, the user is prompted to select from a plurality of possible responses, and wherein a particular response from the plurality of possible responses to each health assertion in the sequence comprises a correct response; receiving, over the one or more networks, a corresponding sequence of responses to the sequence of health assertions from the computing device of the user, each response in the corresponding sequence comprising either the correct response or an incorrect response; based at least in part on the corresponding sequence of responses, determining a mortality classification for the user using the customized mortality table of the health prediction service; and generating, via the interactive user interface, a service customer interface displaying a health service product for the user, the service customer interface enabling the user to redeem the health service product at a specified price that is based at least in part on the mortality classification of the user. 